A few questions about G1
Y. Srinivas Ramakrishna
y.s.ramakrishna at oracle.com
Mon Mar 14 07:26:17 UTC 2011
Hi Alex --
On 3/13/2011 7:51 AM, Alex Aisinzon wrote:
> I guess G1 is more mature and will give it a try as part of some tests
> with the 1.6 JVM.
Definitely more mature, both in performance and reliability. Try 6u25 EA,
or 7 EA.
> I had some questions about G1:
> * Region size: our product does not generate large objects.
> Nevertheless, some of our customers will configure it in a way that
> results in the allocation of large objects. The typical example is that
> our product will be integrated with a document management system and
> that some very large documents (10s of MB or even 100s of MB) will go
> through the JVM that supports our product. I wonder what happens if the
> region size is smaller than these large objects and wonder if one can
> size up the region size pre-emptively to avoid possible negative
> effects. It may also make sense to instrument the JVM to output in the
> GC log the size of the object that caused a region to become full, as it
> would allow to identify such issues.
G1 does treat large objects specially (see the ISMM 2004 paper).
In typical programs the birth-death rates of large objects is
quite small, so I would typically not expect G1 with its
default region size to have any issues. So I would not start
off with the assumption that region size will need any kind of
adjustment. If you have any issues with the default size, you
can revisit on this alias.
> * Pause time: with Sun JVM 1.5, I had experimented with
> ParallelGC, ParallelOldGC and CMS. The two first show long full
> collections. CMS was mostly better but resulted in some rare even longer
> collections, which I attributed to fragmentation, which was in line with
> our applications memory behavior. I wonder what customer/benchmark
> experience is so far with G1 and whether I can hope to avoid these long
> pauses with G1.
G1 is compacting so the expectation is indeed that the long term
fragmentation that is sometimes difficult to avoid with CMS would
be much less of an issue with G1. Our experiences with G1 in the field
are limited, but our expectation is indeed that it will cause far
fewer issues with fragmentation. Please try it out and let us know
of your experiences.
> * Possible tunings to minimize pause times: what would be the
> best tunings to explore with G1, considering that objective of
> containing pause times. From reading
> tml, it seems that MaxGCPauseMillis would be a good tuning. Are they
> other tunings I should consider to test G1 more specifically on the
> pause time dimension?
I believe most of our internal testing has shown that if your
GC pause time and MMU settings are reasonable, G1 does a fairly
good job of containing the pauses withing the requested band.
Sometimes these may be difficult to meet, however, and in those
cases you may need to explicitly size and shape the heap to
avoid concurrent mode failure. Here, our experiences are
again somewhat limited, so experiences from the field will
help us refine our understanding of and tuning of G1 performance
as we go forward.
One thing to keep in mind is that G1 will typically do well
with its heuristics if there is some amount of spare concurrency
available on your platform to deal with its concurrent remembered
set refinement and concurrent marking work, as well as, like CMS,
extra room in the old generation so as to give its concurrent
collection enough headroom to finish collection. If explicitly
tuning the heap, larger heaps with smaller promotion rates
into the old gen, just like in the case of CMS, would also
be favourable to better operation of G1.
I'll let those on our team more familiar with G1 performance
and tuning please chine in with further detail as well as
correct any inaccuracies in my understanding above.
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-dev