RFR: Purge batched matrix cleanup

Aleksey Shipilev shade at redhat.com
Fri Oct 13 15:36:34 UTC 2017


http://cr.openjdk.java.net/~shade/shenandoah/matrix-no-batched/webrev.01/

Before asynchronous region recycling, we had faced problems with matrix cleanups: it takes a while,
and we could not accept it for the pause. There, we had to do deferred, batched, parallel Matrix
cleanup [1] to alleviate STW costs. Now, when region recycling and matrix cleanups are handled in
the concurrent phase, we care about this much less.

Current code handles an interesting complication: we cannot add the batched-cleanup regions to the
free set, for the fear we would clean up matrix for the regions that are used by freeset for
allocation, thus breaking the matrix. On closer inspection, the same thing happens when allocation
paths *assist* with recycling some of the trash regions into empty ones! Which is rare case, but it
is nevertheless a bug.

This can be mitigated by acquiring the heap lock for the batched matrix cleanup, but it would
potentially block allocators for hundreds of milliseconds, which defeats the purpose.

My suggestion is to ditch the batched matrix cleanup code, and leverage async recycling for doing
the right thing. Allocators would normally assist with matrix cleanup, if async recycling is late.
The experiments show this adds around 100us latency on allocation path with 32K regions (which is
above our target anyhow), and it is negligible with the 4K target.

Testing: hotspot_gc_shenandoah

Thanks,
-Aleksey

[1] http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-May/002299.html



More information about the shenandoah-dev mailing list