JDK-8206457 : Code paths from oop_iterate() must use barrier-free access
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 11,12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-07-06
  • Updated: 2021-08-05
  • Resolved: 2018-08-24
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 12
12 b09Fixed
Related Reports
Relates :  
JDK-8221766 - Load-reference barriers for Shenandoah
Relates :  
JDK-8271939 - Clean up primitive raw accessors in oopDesc
Relates :  
JDK-8217325 - Enable inlining of java_lang_Class::oop_size_raw
Description
We have several code paths going out from oop_iterate() methods that lead to GC barriers. This is not only inefficient but outright wrong. oop_iterate() is normally used by GC and GC need to see the raw stuff, not some resolved objects. In Shenandoah's full-GC it's fatal to attempt to read objects's forwarding pointers, because it's temporarily pointing to nowhere land.
Comments
Removed jdk11u-fix labes for the time being because backport is on hold.
16-09-2019
On hold. Unclear if this is still needed after JDK-8221766 backport: only Shenandoah used to fall victim to this trouble.
31-07-2019
Fix Request (11u) This resolves GC problems when objects are accidentally treated by GC barriers when GC walks them. This is known to be problematic at least for Shenandoah. The patch applies cleanly to 11u, passes tier1, tier2 tests. Should come together with JDK-8217325.
25-06-2019