changing the memory settings semi-dynamically vs GateKeeper and signing

[Srinivas Ramakrishna]

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:

>                
> On Feb 20, 2012, at 1:00 PM, Mike Swingler wrote:
> 
>> On Feb 20, 2012, at 12:17 AM, Hendrik Schreiber wrote:
>> 
>>> Hi,
>>> 
>>> I already posted this on the Apple java-dev list - Mike S. recommended taking this topic here.
>>> 
>>> Here's (more or less) the post from java-dev:
>>> 
>>>> I guess most of us who ship java applications ship them with explicit memory settings (-Xmx ...) in the Info.plist file.
> 
> 
> In this whole discussion of passing in command line arguments to .app bundles I do find myself wondering *why* we're doing so.
> 
> Passing -Xmx seems like something we should be trying to eliminate, not support.
> 
> For the sake of argument, let's assume we do not use -Xmx. Right now, GC ergonomics will kick in and do the following
> 
> (From http://www.oracle.com/technetwork/java/ergo5-140223.html#0.0.%20Garbage%20collector,%20heap,%20and%20runtime%20compiler%7Coutline)
> 
> initial heap size of 1/64 of physical memory up to 1Gbyte
> 
> maximum heap size of ¼ of physical memory up to 1Gbyte
> 
> 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?
> 
> 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.