RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress
Roman Kennke
rkennke at redhat.com
Sun Sep 17 12:11:04 UTC 2017
his builds on top of the remove-reduce-storeval-barrier-optimization patch.
It refactors our conc-mark-in-progress flag together with the
satb-in-progress-flag into our new gc-phase-in-progress bitfield.
Notable stuff:
- The patch removes a 2nd check for satb-in-progress in C1. I'll propose
this upstream asap.
- The G1/Shenandoah pre-barriers are refactored such that the
satb-active (G1) and bitfield-concmark-checks (Sheanndoah) are now
separated, while keeping the rest of the inlined SATB-queue-pushing code
shared.
- I noticed the store-checks code is wrong in both x86 and aarch64. We
want to check the storeval-oops only when update-refs is in progress,
but do the check statically, we need to do the check at runtime though
because we might update refs during separate phase or during conc-mark.
This should be fixed, but separately (and probably benefits from folding
update-refs-in-progress into the bitfield too)
- It involves quite a bit of refactoring in C2. I am fairly confident
that it is correct. Would be good to have Roland take a look too. We
should also check with Roland whether or not this is sufficient to allow
commoning loads and checks of the bitfield, or if we need extra
optimization passes for this.
Test: hotspot_gc_shenandoah both x86 and aarch64
http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.01/
<http://cr.openjdk.java.net/%7Erkennke/satb-concmark-flag/webrev.01/>
Roman
More information about the shenandoah-dev
mailing list