JDK-8297914 : Remove java_lang_Class::process_archived_mirror()
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-12-01
  • Updated: 2022-12-19
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.
Other
tbdUnresolved
Related Reports
Relates :  
Description
Currently the mirror objects (i.e., instances of java.lang.Class) are all archived inside a safepoint (VM_PopulateDumpSharedSpace). We  we first make a copy of an existing mirror. Then we remove many states from the copy so that it would have the same state of a mirror object that has just been allocated.

See
https://github.com/openjdk/jdk/blob/56048f9718d1104227795a23c02fa144543c07d0/src/hotspot/share/classfile/javaClasses.cpp#L1154-L1245

This is complicated, and the copy-and-modify inside the safepoint makes it difficult to implement JDK-8296344. It violates the requirements [1] and [2] as stated in JDK-8298600.

======================
Proposal:

During "java -Xshare:dump", for each class K that are loaded by the VM:

- When K's mirror is allocated,  we also allocate a new "scratch" mirror for K. The scratch mirror has the exact states that K needs when it's loaded from the archive at runtime. This allocation is when the current thread is in Java thread mode, so we can avoid allocation inside the safepoint.

- When we are archiving inside the VM_PopulateDumpSharedSpace safepoint, instead of copying the old mirror and resetting its states, we just use the scratch mirror instead.