RFR(XS): 8001425: G1: Change the default values for certain G1 specific flags
bernd-2012 at eckenfels.net
Sat Jan 12 14:26:07 UTC 2013
I know this is G1 ralted, but I just wanted to comment on a different
Am 12.01.2013, 13:39 Uhr, schrieb Kirk Pepperdine <kirk at kodewerk.com>:
> I decided to try G1 because I couldn't get a generational Eden to be as
> small as I needed to ensure frequent enough young gen collections while
> maintaining large enough survivor spaces to capture short lived objects.
In this case I would shoot for a small YG with TenuringThreshold of 0 or 1
resulting in a collection frequency of a few seconds. I cant imagine in a
tight processing loop there are objects which are longer lived than one YG
cycle. But even if there are, they spill over in the CMS where they are
processed in the background.
Having smaller survivors is essential in that configuration as they will
affect the STW pause times of the CMS to the largest degree.
> There was another issue in that the deployment environment didn't leave
> me feeling wonderful about deploying a right sized (small) heap. What I
> was looking to do was deploy with a large heap that behaved right sized
> in order to avoid possible OOMEs. The box has 24 cores and this is a
> perfect case for iCMS as the larger heap caused pause times to creep up
> until a CMS cycle was triggered.. this doesn't happen with iCMS
You dont need iCMS for that, just use a small initiating occupancy and
occupancy only. For example if the applications steady size is 10%, use
this as the occupancy. You could even limit the degree of parallelity for
the CMS in that case, so it will not affect your time critical calculation
threads so much.
More information about the hotspot-gc-dev