RFR: 8306734: Shenandoah: Missing barriers on deoptimization path after Loom integration
Aleksey Shipilev
shade at openjdk.org
Mon Apr 24 15:53:48 UTC 2023
AFAICS, Loom integration ([JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161)) removed the Shenandoah block from `StackValue::create_stack_value` that we added to avoid exposing bad oops during the deopt ([JDK-8224522](https://bugs.openjdk.org/browse/JDK-8224522)). I think that was done to avoid interaction with barrier healing acting on derived pointer bases (?). It was never the issue with Shenandoah barriers, since they were not self-healing on this path anyway. The refactoring for ZGC ([JDK-8296875](https://bugs.openjdk.org/browse/JDK-8296875)) made these paths a bit more explicit, and so we can/should reinstate the Shenandoah barriers block in the new places there.
I'll try to come up with a regression test for it.
Serial, Parallel, G1 are not affected by this, because we do not need load-barriers.
ZGC is not affected by this, because it does the barrier injection in another place. (See [JDK-8224675](https://bugs.openjdk.org/browse/JDK-8224675)).
Additional testing:
- [x] Reproducer from the bug is no longer failing; used to fail 1/2 times on 3 platforms; does not fail after 50 tries
- [x] Linux x86_64 fastdebug `hotspot_gc_shenandoah`
- [x] Linux AArch64 fastdebug `hotspot_gc_shenandoah`
-------------
Commit messages:
- Work
Changes: https://git.openjdk.org/jdk/pull/13613/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13613&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8306734
Stats: 26 lines in 1 file changed: 24 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/13613.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/13613/head:pull/13613
PR: https://git.openjdk.org/jdk/pull/13613
More information about the shenandoah-dev
mailing list