G1gc compaction algorithm

Thu Jul 17 02:54:41 UTC 2014

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
>:

>
>> 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
>>
>>  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>:
>>
>>>
>>>
>>>
>>>  On Wed, Jul 16, 2014 at 9:11 AM, Martin Makundi <
>>> 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 listhotspot-gc-use at openjdk.java.nethttp://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/20140717/901ca217/attachment.html>