G1gc compaction algorithm

[Pas]

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