RFC: Parallel full collection for G1

[Aleksey Shipilev]

Hi,

On 11/09/2016 04:15 PM, Erik Helin wrote:
> currently G1 Full GC is very slow as it is done serially. In some cases
> this might not be optimal.

YES, single-threaded failure mode is very bad and leaves bad impression
for those users who mistuned or otherwise fallen into the failure mode
tarpit. Failure mode should not be unnecessarily painful. See e.g.
 http://cr.openjdk.java.net/~shade/shenandoah/treefragger.txt

> - piggybacking on an already running concurrent mark is preferable when
>   G1 is about to encounter a concurrent mode failure. Typically a
>   concurrent mark is about to be done, unless the dynamic IHOP
>   predictions were completely off. If so, then most of the marking work
>   is already done. This could save significant amount of time in the
>   following compaction phase of that full GC.

Is that concurrent marking information as accurate though? E.g. does
SATB brings the marked objects that are garbage? If so, is there a
failure-failure mode when we don't clean up all the garbage? That would
be bad for a total cleanup phase the full GC is.

> - parallelizing the closures used within the "MarkSweep framework" will
>   result in a parallel full GC that can handle the worst case
>   from-scratch Full GC better.  I.e. even though this algorithm will
>   have to redo marking in a STW pause, it will get the most precise
>   liveness information and so will be able to compact the heap more
>   densely.  This approach can also handle the case when G1 is
>   completely out of regions.

Aha, liveness. In Shenandoah, full GC is almost completely separate STW
mark-compact. And we don't need region liveness data during the full GC,
because full GC does all regions, no need to have liveness data to
select collection set. Avoiding liveness analysis for full-gc-mark
improves performance.

I tend to think that for failure mode, "drop everything on the floor,
and do the accurate mark, linear compaction, and pointer fixups" is the
best way to do it. In Shenandoah, the code cost is not that high to
frown about having a separate impl for full GC, and I think in G1 it
would be the same.

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20161109/aac54a14/signature.asc>