-XX:+MaximizeHeapSize?

[Peter B. Kessler]

Jon Masamitsu wrote:

> We've heard from users in the past that it would be nice if
> there was no maximum heap size limit.  Users say
> they don't know what the limit for their application is and
> have to experiment to find an adequate value.
> 
> I did the following refworkload experiments.
> 
> Ran "reference_client" and "startup2" (sets of client
> application like benchmarks) with the -client
> (uses the serial GC which does not have GC ergonomics) and
> a 1g heap.   The point of this experiment was to see if the
> size of the committed heap increased because of the 1g heap
> size limit.  There was no discernible difference in the
> committed size of the heap nor in the amount of GC work.
> 
> I ran "reference_server" (set of server application like
> benchmarks)  with -server and the parallel GC (does
> has GC ergonomics) with -XX:DefaultMaxRAM=1g (the default)
> and with -XX:DefaultMaxRAM=1700m (the amount of physical
> memory on the platform minus some for
> the OS) and -XX:DefaultMaxRAMFraction=1. The point of this experiment 
> was to see if the
> GC ergonomics drove the  heap to sizes larger that the 1g
> default limit.  As one would expect the heaps for some
> benchmarks grew considerably (up to the higher limits
> in some cases) and for some the heaps did not change.
> 
> I think that these results are not unexpected.  The heap sizing
> policy used by the serial collector depends on the amount of
> live data and the live data for the client like applications
> fit nicely into the 64m default heap size (i.e., the larger
> 1g heap was not needed).  On the larger server like benchmarks run
> with GC ergonomics, the high default throughput goal of GC
> ergonomics means that some benchmarks will just use as much
> heap as they can get in trying to reach the throughput goal.
> 
> I'd like to propose an additional policy under a new command line
> flag.  Let me use MaximizeHeapSize for the name for now.  If
> MaximizeHeapSize is set, the VM will calculate
> the amount of physical memory on the platform and
> try to use that as the upper limit on the heap size.   As
> with the current GC ergonomics the upper limit will
> be ~4g on a 32bit system.   If the VM cannot actually
> reserve that amount of space at initialization, it will
> try reserving some smaller amounts until it succeeds.  There
> will be some minimum size (probably 64m) that it will not
> go below.
> 
> The user would have to turn MaximizeHeapSize on
> explicitly.  It will be off by default until we get some
> experience with it.  Users who turn it on and also use
> GC  ergonomics will manage the heap size via
> a smaller or larger throughput goal (i.e., the larger
> the throughput goal the more heap space the VM will
> try to get to meet the throughput goal).
> For the non ergonomics collectors it should only matter
> if the application would otherwise have bumped into a
> heap limit (i.e., the application would have thrown
> an out-of-memory or just spent too much time doing
> garbage collections because the heap limit set by
> default or on the command line was too small).  In that
> case this change would allow the application to
> get the additional space it needs.  I expect there will
> be some corner cases or bugs where the heap will grow  to
> the limit when it shouldn't.
> Comments on this proposal?

Don't forget to leave some address space for thread stacks,
other libraries, malloc space, etc.  A simple backoff policy
from trying to reserve all of memory might be too simplistic.
I don't know how to estimate beforehand how many thread stacks
an app will need. :-)

			... peter