G1gc compaction algorithm

[Martin Makundi]

Hi!

Thanks for the comment. Bit biased? ;) I would like to see an AI GC... what
I mean by that is artificial intelligence in the sense that WHATEVER you
throw at it, it will tune itself to the best it can better and faster than
any human can. It could do C4 mode and G1 mode and anything in between.
Will that mean increased complexity of code? Yes. But it is justified if
you take into account what it costs not to meet latency targets (immagine
financial services, immagine security services, etc. where there is
practically no tolerance...).

I would like to see Open JDK to win the race ;)

**
Martin


2014-08-27 17:51 GMT+03:00 Thomas Schatzl <thomas.schatzl at oracle.com>:

> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140827/0f9739be/attachment.html>