-XX:+MaximizeHeapSize?

[Paul Hohensee - Java SE]

You might try running the reference_client and startup2 using the client vm
and the parallel collector (UseParallelGC, right?) with a 1gb heap.  I think
you'll see startup time improvements along with a footprint increase.  At
least that's what I saw experimenting with 1.4.2 some years ago.  Got +20%
on startup then, but have no idea what would happen now.

Larger heap sizes really need a parallel collector to avoid excessive pause
times.  1g is about the outer limit of what the serial collector can handle:
the 1.4.2 experiments showed it to be ~20 slower than the parallel collector
on jbb2k with that heap size.  Acceptable, but not optimal.  So thoughtless
use of MaximizeHeapSize could result in an unacceptable gc time increase.
Maybe instead we should have a switch that enables server class machine
heap ergo in the client (and server, though it's somewhat redundant) vm?

Paul

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?
>
>