JEP 307: Parallel Full GC for G1

[Hohensee, Paul]

Imo, all existing collectors can be replaced by variations on G1. The first step was replacing CMS (though admittedly there’s still some way to go with that). The second is to replace the parallel collector with a throughput oriented G1 mode, which requires a parallel STW full GC. Full collections should indeed equal or exceed parallel GC performance, because the old gen is mostly compacted already, so you don’t have to do anything with most old gen regions. You just run the equivalent of a mixed collection that includes all not-mostly-full old regions and promote the entire young gen. If you set throughput mode at VM startup, you shouldn’t need remembered sets either, just the card table. The third step is concurrent/parallel evacuation and continuous concurrent/parallel collection. Shenandoah is almost there, Azul’s C4 is completely there.

You can see this progression in Android too, btw. O-dessert (ships next month) includes a concurrent/parallel region-based GC that replaces the previous variation-on-CMS collector.

Paul

From: hotspot-gc-dev <hotspot-gc-dev-bounces at openjdk.java.net> on behalf of Roman Kennke <rkennke at redhat.com>
Date: Thursday, July 27, 2017 at 1:30 AM
To: Milan Mimica <milan.mimica at gmail.com>, "hotspot-gc-dev at openjdk.java.net openjdk.java.net" <hotspot-gc-dev at openjdk.java.net>
Subject: Re: JEP 307: Parallel Full GC for G1

Hi Milan,

I cannot give an authoritative answer to that, but since Shenandoah is very similar in this respect, and from my experience with Shenandoah, I think that full GC is not a very high priority. It is meant as a last-ditch collection, when all else fails to free enough space. In a good world, with perfect GC heuristics and well behaving applications, it should never happen, and thus performance shouldn't matter much.

However, this world is not ideal, and full GC performance does matter, especially when you got a large heap, and run into it and lose *seconds* (or even minutes) on it.

That being said, we do have a parallel full GC in Shenandoah, and its performance gets close to, and even sometimes exceeds, parallel GC. Maybe it's worth to adopt it for G1? It should be relatively straightforward, because both G1 and Shenandoah are region based. It does compact objects towards the bottom of the heap, while mostly retaining their relative order.

Roman

Am 27.07.2017 um 10:15 schrieb Milan Mimica:
Hi
Can I have just a short explanation why G1 Full GC wasn't implemented as parallel in the first place, given "the assumption that nothing in the fundamental design of G1 prevents a parallel full GC."?


sri, 26. srp 2017. u 23:11 <mark.reinhold at oracle.com<mailto:mark.reinhold at oracle.com>> napisao je:
New JEP Candidate: http://openjdk.java.net/jeps/307

- Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170727/0e3387b0/attachment.htm>