RFR: 8367646: [GenShen] Control thread may overwrite gc cancellation cause set by mutator
William Kemper
wkemper at openjdk.org
Mon Oct 6 22:07:24 UTC 2025
I believe the following events could lead to this assertion failure:
1. Control thread reads the heap's gc cancellation cause as `shenandoah_concurrent_gc`
2. Mutator thread has an allocation failure and sets the heap's gc cancellation cause to `shenandoah_alloc_failure`
3. Control thread uses stale value from `1` and decides to unconditionally clear the cancellation cause
4. Mutator thread assert that gc is still cancelled
The proposed fix here has the control thread use a CAS operation to only clear the gc if the existing value if `shenandoah_concurrent_gc`. This will stop the control thread from erroneously changing the value if a mutator has already set it to `shenandoah_alloc_failure`. A mutator thread may still have an allocation failure after the control thread has cleared the cancellation, but this is normal and expected.
-------------
Commit messages:
- Fix race between mutator and control thread over gc cancellation
Changes: https://git.openjdk.org/jdk/pull/27662/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27662&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8367646
Stats: 11 lines in 3 files changed: 9 ins; 1 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/27662.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/27662/head:pull/27662
PR: https://git.openjdk.org/jdk/pull/27662
More information about the hotspot-gc-dev
mailing list