JEP 141: Increase the Client VM's Default Heap Size

[Michael Bien]

On 02/22/2012 10:10 PM, Peter B. Kessler wrote:
> Michael Bien wrote:
>>
>> On 02/22/2012 04:38 PM, Jon Masamitsu wrote:
>>>
>>>
>>> On 2/22/2012 4:28 AM, Michael Bien wrote:
>>>>  On 02/22/2012 12:48 AM, mark.reinhold at oracle.com wrote:
>>>>> Posted: http://openjdk.java.net/jeps/141
>>>>>
>>>>> - Mark
>>>>>
>>>> additional risks:
>>>>  - JVM may not be able to start
>>>
>>> Specifically, the JVM tries to reserve enough memory at start up
>>> for the heap and fails to initialize if it cannot?
>>>
>>> Will add it.
>>>
>>>>  - could contribute to the false impression that java requires a 
>>>> lot of memory to run (JVMs usually don't like to give memory back 
>>>> to the OS once its in use)
>>>
>>> Is this an impression the user would get because the JVM would not 
>>> start up as you
>>> note above?   The JVM does not necessarily use all the memory it 
>>> reserves.
>> yep. However most GCs are quite lazy (by design) to reach good 
>> throughput. My experience so far showed that GCs have the tendency to 
>> expand the heap at a full GC if there is still room left. Shrinking 
>> heaps happened to me only in constructed tests - never in real 
>> applications (esp. not with default config ;)).
>>
>> i am somehow not very comfortable with the fact that hello world or 
>> an applet would request 1g from the OS. Are there usecases for 
>> applications out there where the developer or admin doesn't know how 
>> much memory is needed? If there are, than a default value would not 
>> help those much anyway (-> expanding heap needed until system limit 
>> is reached). All others set -Xmx  :)
>
> The standard use case is an editor, where the heap needed depends on 
> what's being edited.  To use a text example: a short note versus a 
> book chapter.  As people's expectations grow for what the editor can 
> do, they use it for larger projects.  Sure, at some point they won't 
> have enough heap for some document, and you have to tell them how to 
> work around that limit, but it would be nice if you didn't have to 
> tell everyone how to set -Xmx.  Or, as the implementor, I don't want 
> to ship my code with a script that sets -Xmx1g, because then people 
> complain about reserving 1GB for editing a short note.  (That said, 
> more efficient memory structures in the application are usually a 
> better solution. :-)
>
> This is a specific case of not knowing what the application is going 
> to be used for before it starts up.  Short-lived applet in a browser 
> or the 24x7x365 server running on big iron?  That's why the JVM has 
> default values, and why they aren't always appropriate, and why we 
> discuss the implications when we think about changing them.
>
>             ... peter

Its great that this kind of topics are discussed. I am a little bit 
sceptical that anyone will let the JVM pick a value in production and 
hope the application will work with that default. NetBeans for example 
uses this approach you mentioned to automatically adjust the max heap 
size before startup, I am sure eclipse does something similar in its 
native launcher. Both can do that since both know what the minimum 
requirements are which are needed to run the editor, everything above 
that value is nice-to-have and is set if available.

The real problems are as you mentioned:
  - java has no self contained launcher; jigsaw could help here if it 
would allow to specify jvm flags in the module descriptor
  - the JVM can not figure out what the application requires (basically 
not solvable)
  - the current JVM impl requires an upper heap limit

What would be interesting is a flag which specifies a range. For example 
-Xmx1g_2g. This would tell the JVM to take 2g if possible and scale down 
to 1g if not.

I would even go further and let the JVM print a warning message if xmx 
has not been specified to discourage not portable deployments.

best regards,
michael