JDK-8277654 : Shenandoah: Don't produce new memory state in C2 LRB runtime call
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8,11,17,18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2021-11-23
  • Updated: 2022-06-03
  • Resolved: 2021-11-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18 b26Fixed
Related Reports
Relates :  
JDK-8287227 - Shenandoah: A couple of virtual thread tests failed with iu mode even without Loom enabled.
Relates :  
JDK-8277652 - SIGSEGV in ShenandoahBarrierC2Support::verify_raw_mem for malformed control flow graph
Description
The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
Comments
Changeset: 3d39f09c Author: Roman Kennke <rkennke@openjdk.org> Date: 2021-11-29 16:00:09 +0000 URL: https://git.openjdk.java.net/jdk/commit/3d39f09c6cdc875b44147b4e84e496b6abf93996
29-11-2021