G1 feedback

[Todd Lipcon]

Hi Alex,

I've had similar results - see my threads from a few months back on this
mailing list.

The summary is that, when there is a tight pause bound, some regions will
accumulate which have estimates that are "stuck" higher than the goal. As
these accumulate, they're never collected, which means that memory usage
slowly grows until a full GC is required.

The two situations that caused this in my experiments were:
1) The JVM got context-switched out for several scheduling quanta during the
"other" portion of a non-young region collection. Because "other" time is
considered constant overhead, even mostly-garbage regions were carrying this
as part of their estimate, causing all non-young regions to be deemed "too
expensive". I fixed this with a patch to notice when the "other time"
estimate was greater than the pause goal and decay it back towards 0.

2) A bad region accumulates many inter-region references in its "remember
set", overflowing into the coarse rset. Once the coarse rset has been used,
there's no facility to "uncoarsen" the rset entries even after all the
referring regions are dead. If the number of coarse entries is high enough
that the time estimate is greater than the pause time goal, then again, this
region will never be collected, and memory will fill up until a full GC. I
wrote a patch to improve the time estimation for coarse rset entries based
on the liveness info in the coarse regions. This helped somewhat for my
application.

Let me know if you'd like to try these patches out, I can dig them up again
(or you might find them in the mailing list archives).

-Todd

On Fri, Apr 1, 2011 at 11:48 AM, Alex Aisinzon <aaisinzon at guidewire.com>wrote:

> Hi all
>
>
>
> Thoughts on this feedback about G1?
>
>
>
> Take care
>
>
>
> Alex A
>
>
>
> *From:* Alex Aisinzon
> *Sent:* Saturday, March 26, 2011 6:46 AM
> *To:* hotspot-gc-use at openjdk.java.net
> *Subject:* G1 feedback
>
>
>
> Hi all
>
>
>
> I experimented with G1 and Sun JDK 1.6 update 24 and ran two long running
> tests (8 hours) with it:
>
> With " -server -XX:+UseG1GC -XX:+UseCompressedOops -Xms24576m -Xmx24576m",
> most pauses were very short. 4 pauses were around 7 seconds and 4 at 34
> seconds.
>
> I then added the objective of keeping the longest pause around 1 second and
> used "-server -XX:+UseG1GC -XX:MaxGCPauseMillis=1000 -XX:+UseCompressedOops
> -Xms24576m -Xmx24576m". Most pauses were a little above 1 second except for
> one pause at 8 seconds and one at 57 seconds.
>
> The server is a dual X5570 (8 cores total) and has 48GB of RAM. Its average
> CPU utilization was around 60-65% so it was not over-used.
>
> Everything would be perfect if it were not for the 7, 34 and 8, 57 seconds
> pauses.
>
> What would you recommend I do to either reduce these longer pauses or give
> insights into what happened so that G1 can avoid these very rare but pretty
> long pauses in the future?
>
>
>
> Thanks in advance
>
>
>
> Alex A
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20110401/fa01154a/attachment.htm>
-------------- next part --------------
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use