RFR: 8242054: Shenandoah: New incremental-update mode

Roman Kennke rkennke at redhat.com
Thu Apr 2 19:23:41 UTC 2020


Some of our users like some properties of the marking/traversal
behaviour of the Traversal mode, but would also like the benefits and
ergonomics of the normal mode. It turns out that it is relatively easy
to transplant the barrier-model of Traversal mode into the regular mode.
This is essentially a variant of the well-known incremental-update model
of concurrent marking.

We already have all the barrier-foo that we need from the Traversal
mode. The following modifications are required to make it work with
regular mode:

- Arraycopy-barriers must mark through src instead of dst (we're
interested in the new-values not in the previous-valuses). They must
also trigger when dest is uninitialized (esp in the ASM prologue calls)
- Related to this, clone-barriers now also need to mark through the
src-object. (SATB doesn't need this because destination is by definition
uninitialized).
- Both clone and arraycopy-barriers can skip marking the src obj/array
if the src is allocated-after-mark-start: in this case it's guaranteed
by the barrier model than any reference in them must already have gone
through a barrier.
- C2 code sees some adjustments to allow marking-active checks when
expanding ShenandoahStoreValEnqueueBarrierNode. It previously only
checked HAS_FORWARDED to account for Traversal-active. It also adds
MARKING to the state-check for the clone-barrier.
- I removed the flags-checks from aggressive/compact/static heuristics.
This is now checked in shenandoahNormalMode.cpp (and is consistent with
adaptive)
- I introduced a new mode called ShenandoahIUMode, mapped to
ShenandoahGCMode=iu, which sets the flags for this new mode.
- I added no testing yet. The plan is to change traversal tests to iu
tests if/when Traversal gets eliminated.
- I did, however, test everything in shenandoah/jdk by changing the
default mode to iu.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8242054
Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.00/

Testing: hotspot_gc_shenandoah clean. Deeper testing with shenandoah/jdk
is looking good too. I ran specjvm and specjbb many times, and have seen
no problems. Performance looks similar to normal-mode too. One early
tester has confirmed that behaviour is as-expected like with traversal-mode.

Can I please get a review?

Thanks,
Roman




More information about the hotspot-gc-dev mailing list