G1gc compaction algorithm

Thu Jul 17 01:46:24 UTC 2014

>
>
> 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/35f2c1e8/attachment.html>