JDK-8194741 : Refactor oops in constant pool from CDS to use the Access API
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-01-08
  • Updated: 2019-06-20
  • Resolved: 2018-01-15
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 11
11 b01Fixed
Related Reports
Relates :  
JDK-8195107 - CDS broken due to 8194741
Relates :  
JDK-8194759 - Support caching class mirror objects
Relates :  
JDK-8179302 - Pre-resolve constant pool string entries and cache resolved_reference arrays in CDS archive
Description
CDS allows mapping in objects to the Java heap from archives.
In particular, the constant pool can load in resolved_references from an archive.
If this installation of the archived oops happens during, e.g. G1 concurrent marking, then a SATB enqueue barrier is manually performed in order to register that this oop is now strongly reachable, which is a requirement for being allowed to add edges to the oop from the object graph during concurrent marking.

It would be neat if there was a more GC agnostic way of doing this through the Access API.
Comments
Erik, thanks for looking into this! That would be most helpful as we are adding more types of archived objects. I'm getting very close to archive the class mirror objects. Currently I handle the mirror objects the same way as the archived resolved_references when archived the object becomes 'in use' at runtime.
08-01-2018