RFR (S): 8154528: Reclaim regions emptied by marking in Remark pause

[Thomas Schatzl]

Hi Aleksey,

On Mon, 2018-04-16 at 13:29 +0200, Aleksey Shipilev wrote:
> On 04/16/2018 01:13 PM, Thomas Schatzl wrote:
> > > CR:
> > > https://bugs.openjdk.java.net/browse/JDK-8154528
> > > Webrev:
> > > http://cr.openjdk.java.net/~tschatzl/8154528/webrev/
> 
> The patch looks good.

  thanks for your review.

> 
> We do the similar thing in Shenandoah, it is surprisingly effective
> on many workloads. Although Shenandoah does this by marking those
> regions as "trash" during the pause, and then concurrently
> cleaning them up after leaving the pause, which saves a few
> milliseconds of pause time. It matters in two non-obvious places: a) 

You mean concurrently cleaning these regions?

G1 did the concurrent cleaning as well, but it has been removed for now
because
- reclaiming these regions is really really fast
- it adds some additional necessary synchronization (lock) in the
region allocation path. This shows up in pause time sometimes
particularly with smaller region sizes.

Now if G1 had lock-free region allocation (and lock free addition to
the free-list), this would not matter at all. At the moment the
additional lock has been considered worse than the additional
millisecond or so (in product code) even for large heaps.

> if you ZapUnusedHeapArea (enabled by default in fastdebug) during the
> pause, many of time-sensitive bugs get hidden; b) test time gets
> larger, because we would spend much more time in STW;
> 
> Another related idea that we implemented in Shenandoah is immediate-
> garbage shortcut: when we have enough of these reclaimable regions
> (e.g. 95% of total garbage), we shortcut the cycle, wasting no
> more cycles for collection. I think it is more beneficial for G1,
> because you can avoid going to STW for evacuation.

If I understand your suggestion, in this case the mixed phase won't be
started already :)

As for frequency of empty regions during remark, there "typically" arenot a lot of empty regions to reclaim any more. G1 reclaims some kind of empty humongous regions all the time (every gc pause), for exactly this reason.

Of course it would be really nice if the remembered set were improved
to be able to reclaim even more empty regions during regular gc
(basically its current implementation prevents efficiently doing that).

Thanks,
  Thomas