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