On 03/08/2010 11:11 PM, Vincent Fourmond wrote: > Pablo Duboue wrote: >>> All right... >>> >>> Then, maybe I could add a function to java-wrappers that would find >>> out what is a 'good default' for that parameter, getting something more >>> than the memory required but still reasonably less than the memory >>> present on the machine ? >> >> If you want to go in that direction, you might want to add also >> pointer compression in AMD64 (-XX:+UseCompressedOops), which makes a >> huge difference with respect to minimum heap sizes in AMD64. Otherwise >> what it's OK for 32-bits might be way too little for 64 bits. >> >> http://wikis.sun.com/display/HotSpotInternals/CompressedOops >> http://java.sun.com/javase/6/webnotes/6u14.html >> >>> Would that be useful for anyone else than me ? >> >> I find it difficult to imagine how would you automatically determine >> the heap size based on the ideas you sketched in your earlier >> comments. If what you propose actually solves the problem, then you >> can actually write a patch for upstream to do that within the JVM :-) >> :-) > > My idea would be something just like "all the memory minus a bit", > which would make java apps behave somehow like the other programming > languages with respect to memory allocation. > > The reason why this isn't done by default in the JVM (and why it > definitely shouldn't be done that way) is that the JVM puts a strong > emphasis on security: setting a limit on the resources a web applet can > take seems like a good idea.
No, that's not the main reason. It's done that way because the heap is contiguous, so has to be pre-allocated. The key issue here is the setting of vm.overcommit_memory and vm.overcommit_ratio. If you set the ratio large enough you can allocate a large heap without any problems. Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9615e4.1090...@redhat.com