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

[Peter B. Kessler]

I'm in favor of a heap that doesn't need to have a maximum specified, but instead allow the heap to grow as the application demands.  We know how to do that, it's just a matter of programming.  Compare this to C programs, which just call malloc() until they finish, or run out of address space.  There are lots of options along the way: an admin might want to specify a maximum for an application on a shared machine; a launcher might want to see what else was running on the machine and adjust the heap to be polite; the JVM might want to limit the heap to what is available without causing paging; aggressive collection might cause the heap to shrink; etc.

			... peter

Michael Bien wrote:
> 
> 
> 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
> 
> 
> 
>