G1 feedback

[Alex Aisinzon]

Hi Todd

 

This is very interesting. I feel I need to read some additional material
about G1 to fully understand your explanation. I guess the research
paper on it would help. I will plan to read it.

In any case, I am happy to give your patch a try. The challenge is that
I am not well set to rebuild G1. Is there a way I could get the java
binary/executable with the patch included?

 

Thanks in advance

 

Alex A

 

From: Todd Lipcon [mailto:todd at cloudera.com] 
Sent: Friday, April 01, 2011 12:05 PM
To: Alex Aisinzon
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: G1 feedback

 

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: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20110401/73b13690/attachment-0001.html