Bug ID: JDK-8245597 Avoid using ClassLoaderDataGraph::loaded_classes

Type: Enhancement
Component: hotspot
Sub-Component: runtime
Affected Version: 15

Priority: P4
Status: Closed
Resolution: Duplicate

Submitted: 2020-05-22
Updated: 2021-01-07
Resolved: 2020-08-06

Versions (Unresolved/Resolved/Fixed)

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
tbdResolved

During -Xshare:dump, we run the following code to find all classes to be archived:

http://hg.openjdk.java.net/jdk/jdk/file/0348e9be94d1/src/hotspot/share/memory/metaspaceShared.cpp#l1582

  CollectClassesClosure collect_classes;
  ClassLoaderDataGraph::loaded_classes_do(&collect_classes);

However, CDS already maintains DumpTimeSharedClassTable that contains all possible classes that can be archived, and most of the CDS code iterates over this table (e.g., when writing the shared dictionaries). There's a potential risk that the ClassLoaderDataGraph may get out of sync DumpTimeSharedClassTable (unlikely but who knows), so it's better for all CDS code to exclusively use DumpTimeSharedClassTable.

NB., the above is only for -Xshare:dump (aka static dumping). We don't call ClassLoaderDataGraph::loaded_classes_do during -XX:ArchiveClassesAtExit (aka dynamic dumping).