G1gc compaction algorithm

[Thomas Schatzl]

Hi Martin,

On Wed, 2014-08-27 at 06:38 +0300, Martin Makundi wrote:
> Good article:
> http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf


  we are aware of this product and a few other papers or implementations
for a fully concurrent compacting collector.

> 2014-08-21 17:21 GMT+03:00 Martin Makundi
> <martin.makundi at koodaripalvelut.com>:
>         Hi!
>         
>         Why doesn't the g1gc operate like azul c4 is described to
>         operate:
>         http://www.azulsystems.com/technology/c4-garbage-collector
>         "fully concurrent, so it never falls back to a stop-the-world
>         compaction"?

Fully concurrent vs. STW is a trade-off. Years ago, for G1 it has simply
been decided that the STW mechanism has more advantages than benefits.

One of the problems of fully concurrent collectors is usually the impact
on throughput (~15-20% less), another one is typically highly increased
complexity of the code.

Iirc C4 does not give a guarantee about always being fully concurrent;
actually the paper mentions at least one case where it "stops the world"
too. Not sure if they have been fixed (or is considered worth fixing).
There may be more of these corner cases, like that the application needs
to be at least somewhat cooperative (i.e. in terms of live set, max/avg
allocation rate) just like in G1 to avoid the equivalent of full gcs.

I.e. most likely "never" with some fine print.

I may be wrong, maybe somebody with experience with C4 can chime in.

At this time we will continue to work on making G1 even more useful in
more applications (larger heaps, providing more consistent lower pause
time "guarantees"). :)

Thanks,
  Thomas