JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector

[Srinivas Ramakrishna]

On Tue, Jan 21, 2014 at 1:38 AM, Thomas Schatzl
<thomas.schatzl at oracle.com>wrote:

> ....
> I can imagine this was how the non-generational G1 worked initially too.
> It did not work out to have the expected performance, or at least it has
> been shown extremely beneficial for a few reasons to by default collect
> the nursery regions. Probably mainly because G1 would select the regions
> it recently allocated into anyway.
>
> As you mention, Shenandoah will/should likely also automatically do the
> same too.
>
> Again, note that young gen in G1 is really mostly about selecting the
> "best" regions for reclamation. You may notice most code in G1 is only
> interested in the collection set, not the young gen.
>
> > > As an aside, I have no bias for generational collectors but I have seen
> > > places where having a continuously running collector would have been
> very
> > > advantageous. For example, I had one case we had a hard 16ms time
> budget on
> > > bursts of fixed units of work. In that case the work could be
> completed in 5
> > > or 6 ms which left 10ms for GC (should it decide to run and undoubtably
> > > would have run in the middle of the 5-6ms burst of work) but we could
> never
> > > get the collector to run consistently in under 10ms without risking an
> OOME.
> > > I’m pretty convinced that continuous collection policy would have
> helped us
> > > meet that goal and we had plenty of CPU to throw at the problem so….
>
> I think another problem related to hardware is memory, not so much CPU.
> As you mention, there are typically always enough CPUs to throw at the
> problem. Increasing the amount of memory starting from a certain
> threshold gets comparatively expensive, and managing to have good memory
> bandwidth (at good latency) even more so.
>
> Others probably have more insight into that.
>
>
I have exactly the same sentiments. In my experience, much Java code today
is highly
generational, and the increased headroom requirements of Shenandoah would
limit
its applicability at the ultra-large end of the heap size spectrum,
especially when the allocation
and death rates are very high. It seems to me that any collector that wants
to support ultra-high
allocation and death rates would have to be generational, to be competitive.
On the other hand, Shenandoah might be targeting a different market where
very low pause-times
are more important, the object allocation and death rates are relatively
moderate, and adding
memory is still cheap because programs typically do not need very large
heaps.

Echoing Thomas, and as mentioned in another email, I'd suggest that we
might also want to
explore a hybrid/generational version of Shenandoah, with a scavenging
young generation collector
and Shenandoah running in the old generation.

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