Peter B. Kessler
Peter.Kessler at Sun.COM
Wed Jul 11 17:45:54 UTC 2007
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. :-)
More information about the hotspot-gc-dev