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

[Michael Bien]

  thanks for brining this up. Thats actually a point i didn't mention 
explecitly since i always thought it would be a lot of work to rewrite 
the GCs to work with a non contiguous
heap. This would be certainly the best default option for desktop 
applications. Looking forward to some JRockit-Hotspot integration :)

regards,
michael

On 02/23/2012 02:49 AM, Peter B. Kessler wrote:
> 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
>>
>>
>>
>>
>
>

-- 
http://michael-bien.com/