changing the memory settings semi-dynamically vs GateKeeper and signing

[Jon Masamitsu]

On 2/21/2012 9:49 PM, Srinivas Ramakrishna wrote:
> Good points... It's a good idea to cross- post this over to hotspot-gc-dev since it's relevant to "client ergonomics" or current lack thereof....
>
> Sent from my iPhone
>
> On Feb 21, 2012, at 20:54, Andrew Thompson<lordpixel+openjdk at mac.com>  wrote:
>
>> ...
>> But why should this be the behavior? Apps written in Objective C don't self limit, so why not make Xmx default to physical RAM size?

Hotspot reserves the address space for the heap at initialization.  
Having it automatically
grab 1gb seems unfriendly to other users of address space within the 
process and may
exclude other process from starting up (depending on how over 
subscription of memory
is handled).

A smaller  limit on the size of the heap also limits the pause time an 
application will see.
It can also limits throughput but I believe there are many users who 
prefer the low pause
more often rather than the larger pauses less often.

Regarding shrinking the heap and giving back the memory, yes, the 
hotspot should do
that.

Jon

>> I can give at least a partial answer: because most of the Garbage Collectors available for Java NEVER shrink the heap once it grows. What then ends up happening is a "high water mark" effect. Say you have an application that needs to allocate 1.5GB of memory during startup, but once it is up and running it then only needs 500mb? Well, under most Java GCs today the heap is going to grow to at least 1.5GB and never come down again. Let me be clear; the 1.5 GB heap will have 500mb of data and 1gb of free space; it collects the garbage but it never shrinks (gives memory back to the OS)..
>>
>> In fact, as far as I know only the old serial GC ever gives back memory, but that's not the default collector in a 64bit VM. Parallel GC is. One can use the ergonomics goal settings mentioned here:
>>
>> http://www.oracle.com/technetwork/java/ergo5-140223.html#1.1.1.Maximum%20pause%20time%20goal%7Coutline
>>
>> These influence whether the VM collects or grows the heap, but they have no impact on shrinking the heap under the parallel collector. Don't take my word for it,  there's a thread on the hotspot-GC-dev list about this, a patch is proposed but the conversation peters out
>>
>> http://markmail.org/message/xalkitas66s3w7pt#query:+page:1+mid:ci5y6rkvdswbwwhs+state:results
>>
>> This limitation has a chilling effect as if at anytime an application requires more memory the heap will grow, but when that turns out to be a temporary condition and garbage is collected the heap does not shrink back down again. What person shipping a client-side app would take that risk?
>>
>> What I'd like to see is something  like
>>
>> initial heap size is ?1/64? physical memory
>>
>> maximum heap size is equal to physical memory
>>
>> With heap shrinking working, one could risk not setting Xmx and letting it be physical RAM size because even if the app temporarily uses this much memory, it'll give back when it calms down.
>> But since heap shrinking does not work with most GCs, Xmx is here to stay, I fear.