G1gc compaction algorithm

[Thomas Schatzl]

Hi,

On Wed, 2014-07-16 at 09:45 +0200, Pas wrote:


> On Wed, Jul 16, 2014 at 9:11 AM, Martin Makundi
> <martin.makundi at koodaripalvelut.com> wrote:

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

You mean in-place space reclamation during young gc as it occurs during
full gc. Generally, as long as there are free regions, the current
scheme of evacuating into other areas is sufficient and simpler (read:
faster).
This does not say that we won't think about it in the future if it is
useful (e.g. to recover more nicely from evacuation failures).

I agree with Yaoshengzhe that JDK-8038487 is what you should look out
for. About the 60-70% occupied heap - that the value might be so low
because of fragmentation at the end of humongous objects; see
https://bugs.openjdk.java.net/browse/JDK-8031381 for a discussion.
However since full gc can reclaim enough space to fit these objects,
this does not seem to be the case. This may also mean that these large
objects are simply very short-living if the heap after full gc
dramatically decreases, so something like JDK-8027959 will help.

The most proper solution for your case can only be found out by
PrintHeapAtGC/Extended (at every GC) or G1PrintRegionLivenessInfo (at
end of every marking) output.

If you have lots of arrays that just straggle a region boundary, and so
are basically occupying twice their size, an alternative to get back
some memory would be to size the arrays used slightly smaller.

> 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

No. At the moment only marking or full gc clears unreachable (dead)
humongous objects.

Only JDK-8027959 (which is out for review) removes this restriction.
There are some restrictions to this at this time, but they they are
purely due to cost/benefit tradeoffs.

They are sort-of logically assigned to to the old generation. Which
means that humongous region treatment breaks pure generational thinking
with that change.

>  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).

JDK-8049332 only mentions full GCs so I cannot follow that line of
thought.

Thanks,
  Thomas