Re: Reasonable values for the -Xmx parameter ?
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.
Reply to: