JEP 307: Parallel Full GC for G1

[Roman Kennke]

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/3e5499d2/attachment.htm>