changing the memory settings semi-dynamically vs GateKeeper and signing

Andrew Thompson lordpixel+openjdk at
Tue Feb 21 20:54:13 PST 2012

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


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:

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

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.

More information about the macosx-port-dev mailing list