G1gc compaction algorithm

[Yu Zhang]

Martin,

I took a look at the log you posted.  Here are my observations:
1. at timestamp 125.893, the Eden size(300g) for the mixed gc is messed 
up.  Probably a bug.
2. For most of the time, eden size is 1.4g, survivor 150m, the rest is 
old gen.  I am not sure how much of the old gen is used for humongous 
allocations.  But it seems there are some tunings you can try to help 
mixed gc:
   - old regions added to cset is 2-14 for mixed gc.  Most of the time 
the reason is 'predicted time too high'.  You can try either increase 
-XX:MaxGCPauseMillis to a higher value, or decrease 
-XX:G1MixedGCCountTarget (currently it is 80) so that more old regions 
can be added.
   - you have -XX:G1MixedGCLiveThresholdPercent=10 which means if the 
region is more than 10% full, it will not be added to cset. This is too low.
3. marking does clean ~1.5 space.
4. heap usage after full gc is 13g.  You should be able to clean more if 
mixed gc is tuned better.  Assuming most of the old regions are not 
humongous.  To confirm that, you can add -XX:+G1PrintRegionLivenessInfo

Thanks,
Jenny

On 7/16/2014 1:19 AM, Martin Makundi wrote:
> Hi!
>
> Here's today's log from today's first Full GC.
>
> 81.22.250.165/log <http://81.22.250.165/log>
>
> Our app parameters:
>
> -server -XX:InitiatingHeapOccupancyPercent=0 
> -XX:+UnlockExperimentalVMOptions -XX:G1MixedGCLiveThresholdPercent=10 
> -XX:G1OldCSetRegionThresholdPercent=85 -Xss4096k -XX:MaxPermSize=512m 
> -XX:G1HeapWastePercent=1 -XX:PermSize=512m -Xms20G -Xmx30G -Xnoclassgc 
> -XX:-OmitStackTraceInFastThrow -XX:+UseNUMA 
> -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=128m 
> -XX:-UseStringCache -XX:+UseGCOverheadLimit -Duser.timezone=EET 
> -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+AggressiveOpts 
> -XX:CMSInitiatingOccupancyFraction=90 -XX:+ParallelRefProcEnabled 
> -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=75 
> -XX:G1MixedGCCountTarget=80 -XX:+UseG1GC -XX:G1HeapRegionSize=5M 
> -XX:GCPauseIntervalMillis=1000 -XX:+PrintGCDetails -XX:+PrintHeapAtGC 
> -XX:+PrintAdaptiveSizePolicy -XX:+PrintGCDateStamps -XX:+PrintGC 
> -Xloggc:gc.log
>
>
> 2014-07-16 10:45 GMT+03:00 Pas <pasthelod at gmail.com 
> <mailto:pasthelod at gmail.com>>:
>
>
>
>
>     On Wed, Jul 16, 2014 at 9:11 AM, Martin Makundi
>     <martin.makundi at koodaripalvelut.com
>     <mailto:martin.makundi at koodaripalvelut.com>> wrote:
>
>
>             On Wed, 2014-07-16 at 10:02 +0300, Martin Makundi wrote:
>             > > > +PrintHeapAtGC -XX:+PrintHeapAtGCExtended .
>             >
>             > Does it print only on Full GC or any GC? Any gc might be
>             an overkill.
>
>             Unfortunately any GC :/
>
>             >
>             > >  You want that probably:
>             > > https://bugs.openjdk.java.net/browse/JDK-8038487
>             >
>             > I cannot comment (didn't find a way to register as user)
>             on that entry
>             > but you could add a comment on my behalf that  
>             "continuous parallel
>             > compaction"  would be nice.
>
>             I can add a comment, but what do you mean with "continuous
>             parallel
>             compaction" if I may ask, and what exact purpose does it
>             serve?
>
>             The terms are too generic to me to discern any particular
>             functionality.
>
>
>         I mean that currently compacting occurs on full gc meaning
>         stop-the-world. Would be nice if compacting would occur in
>         parallel while app is running and taking into account all
>         timing targets such as MaxGCPauseMillis etc.
>
>
>     In case of G1, compacting occurs in the mixed phase too. The
>     documentation
>     (http://www.oracle.com/technetwork/articles/java/g1gc-1984535.html) is
>     unclear, but we can assume that even unreachable (dead) humongous
>     objects are collected in that phase (for example the description
>     of this bug https://bugs.openjdk.java.net/browse/JDK-8049332
>     implies that we're correct), they're just not moved (evicted, as
>     they basically always represent one region).
>
>     G1 does "continous paralell compaction" (the eviction runs is the
>     important difference between a young GC and a mixed GC, and it can
>     and does use multiple threads, so it's paralell).
>
>     So, if G1 runs continously (because you set maxmilis and IHOP
>     low), and you still run into stop-the-world hammertime good old
>     full GC mode, then either your application is leaking memory
>     (still has references to large object graphs, or just a few large
>     objects) or simply has a load too large (so memory pressure is too
>     high, because the working set is simply too big, so G1 doesn't
>     have any headroom to make the magic in the specified maxmilis).
>
>     It would be nice, of course, if it could tell us which one is
>     happening, but currently the best practice is to try to simulate
>     different loads.
>
>
>         **
>         Martin
>
>
>             Thanks,
>               Thomas
>
>
>
>     Pas
>
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140716/987fbd59/attachment-0001.html>