G1 feedback: adaptive size problems ?

[John Cuthbertson]

Hi Simone,

Thanks for trying out G1. I'll try and answer your questions.


On 4/30/2012 6:15 AM, Simone Bordet wrote:
> Hi,
>
> using JDK 1.7.0_04, Ubuntu Linux 12.04 64 bit, attached you can find
> the GC log of my Java IDE.
>
> Startup options:
>
> -Xmx1024m
> -Xms1024m
> -Xmn512m
> -XX:+UseG1GC
> -XX:MaxGCPauseMillis=200
> -XX:+PrintGCDetails
> -XX:+PrintGCDateStamps
> -XX:MaxPermSize=256m
> -XX:ReservedCodeCacheSize=64m
> -ea
>
> I noticed that sometimes G1 performs a "to-space overflow" collections
> that last way more than the target pause (in my case, up to 3+
> seconds), and that after these kind of pauses the survivor spaces get
> a big size reduction (e.g from 64 MiB to 6 MiB), which causes more
> "to-space overflow" collections until a Full GC seems to restore
> normal conditions.

"to-space overflow" is what we call an evacuation failure or promotion 
failure. This happens when we run out of heap regions during the GC (for 
either/both survivors and promoted objects). As you can see this can be 
expensive. When an evacuation failure occurs, the GC still has to 
continue - we have a mixture of successfully and unsuccessfully copied 
objects and we have to fixup references to the objects that were 
successfully copied.  Objects that were not successfully copied are 
effectively tenured in place. Any updates to remembered sets of regions 
in the collection set (which we would ordinarily discard) have to be 
regenerated.

As a result of the in-place tenuring, the old generation occupancy will 
increase (hopefully temporarily). Also if the evacuation failure occurs 
during marking - the in-place tenuring may make some regions look like 
bad candidates for collection during the following set of mixed GCs (it 
can look like they are fairly full of live data and hence expensive to 
collect).

There are a few things to try and stop the evacuation failure. The first 
is increase the heap size. Another is to increase G1ReservePercent 
(default 10). This flag creates a false ceiling in the heap and 
increasing that ceiling can reduce evacuation failures; decreasing it 
might allow the heap to expand a little - which may be enough to get the 
application running on the verge of getting an evacuation failure but 
without actually getting one. Starting marking earlier by reducing 
InitiatingHeapOccupancyPercent (default 45) or increasing the number of 
marking threads (ConcGCThreads) may help marking complete earlier and 
free up some space at the end of marking.

> At one point I see in the log this entry:
>
>     [Eden: 0B(512M)->0B(512M) Survivors: 0B->0B Heap: 1002M(1024M)->1002M(1024M)]

This looks weird but indicates an empty collection set - most likely 
because we can't allocate a region for the application to allocate 
into.  I'll take a look at the full GC log and see if any other 
suggestions come to mind.


Regards,

JohnC