[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: