JDK-8298601 : Refactor archiving of java.lang.Module objects
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-12-12
  • Updated: 2023-01-09
  • Resolved: 2023-01-04
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 21
21 b04Fixed
Related Reports
Relates :  
Description
The current implementation of java.lang.Module requires the use of "archived oops" via the HeapShared::find_archived_heap_object API:

https://github.com/openjdk/jdk/blob/c7aca73177339f931f7dfb6627365548a32874f7/src/hotspot/share/classfile/moduleEntry.cpp#L474

    oop m = HeapShared::find_archived_heap_object(module_obj);
    assert(m != NULL, "sanity");
    _archived_module_index = HeapShared::append_root(m);

This violates requirement [1] of JDK-8298600 and should be refactored.

****** 

Also, we should add verification code that all the archived java.lang.Module oops and their corresponding ModuleEntry objects (if any) must be in a consistent state. More comments should be added to explain how these objects are stored into, and loaded from, the CDS archive.



Comments
Changeset: 82deb5ca Author: Ioi Lam <iklam@openjdk.org> Date: 2023-01-04 04:03:43 +0000 URL: https://git.openjdk.org/jdk/commit/82deb5ca615f70634f8cd84836265d01edd1c5a5
04-01-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11715 Date: 2022-12-19 05:28:39 +0000
19-12-2022