G1gc compaction algorithm

[Martin Makundi]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140716/f6cd75b2/attachment.html>