JDK-8231087 : Shenandoah: Self-fixing load reference barriers for C1/C2
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8-shenandoah,11-shenandoah,14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-09-16
  • Updated: 2020-05-06
  • Resolved: 2019-09-18
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 14
14 b15Fixed
Related Reports
Relates :  
JDK-8232010 - Shenandoah: implement self-fixing native barrier
Relates :  
JDK-8232992 - Shenandoah: Implement self-fixing interpreter LRB
Relates :  
JDK-8244510 - Shenandoah: invert SHC2Support::is_in_cset condition
Relates :  
JDK-8233021 - Shenandoah: SBSC2::is_shenandoah_lrb_call should match all LRB shapes
Relates :  
JDK-8238153 - CTW: C2 (Shenandoah) compilation fails with "Unknown node in get_load_addr: CreateEx"
Relates :  
JDK-8233165 - Shenandoah:SBSA::gen_load_reference_barrier_stub() should use pointer register for address on aarch64
Sub Tasks
JDK-8237013 :  
Release Note: Shenandoah self-fixing barriers - Resolved
Description
One significant contributor to Shenandoah's barrier performance is the LRB-midpath performance: when heap is unstable *and* the loaded reference is in cset, we then check if the object is forwarded and if not, call out into the slow-path. A way to avoid this is to update references right in the slow-path. This avoids triggering the cset-check on next access of the same field.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/bc0648405d67 User: rkennke Date: 2019-09-18 19:00:54 +0000
18-09-2019