G1gc compaction algorithm
Yu Zhang
yu.zhang at oracle.com
Thu Jul 17 03:07:31 UTC 2014
This is a diagnostic parameter, you need to apply with
-XX:+UnlockDiagnosticVMOptions -XX:+G1PrintRegionLivenessInfo
Thanks,
Jenny
On 7/16/2014 7:54 PM, Martin Makundi wrote:
> I get error:
>
> Improperly specified VM option 'G1PrintRegionLivenessInfo'
>
> This is with java 1.7 u 55
>
>
> 2014-07-17 4:46 GMT+03:00 Martin Makundi
> <martin.makundi at koodaripalvelut.com
> <mailto:martin.makundi at koodaripalvelut.com>>:
>
>
> 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.
>
>
> Does it attempt to do any mixed gc if it cannot do
> all G1MixedGCCountTarget or is the value G1MixedGCCountTarget just
> an upper limit? If it just is an upper limit we could keep it at
> 80 or higher?
>
> - 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.
>
>
> Thanks, we thought this works the opposite, now switched to 90.
>
> 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
>
>
> Added this to logs, will get back at this with new results.
>
> **
> Martin
>
>
> 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 <mailto: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/2385c6ab/attachment-0001.html>
More information about the hotspot-gc-use
mailing list