RFR: 8262376: ReplaceCriticalClassesForSubgraphs.java fails if --with-build-jdk is used

[David Holmes]

On Thu, 29 Apr 2021 00:32:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When CDS tries to load sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo from the classlist, the VM has already finished the "early" bootup phase. To load this class, the module system tries to create an instance of jdk.internal.module.SystemModuleFinders$SystemModuleReader and store that into the ArchivedBootLayer. However, the SystemModuleReader class is also not yet loaded, so the VM loads it on demand. As a result, SystemModuleReader is treated as a "non-early class".
> 
> The problem is now ArchivedBootLayer refers to a non-early class. At runtime, if JVMTI ClassLoadHook is enabled, HeapShared will refuse to load ArchivedBootLayer from the archived heap. The reason is explained by this in heapShared.cpp:
> 
> 
> // Note: if a ArchivedKlassSubGraphInfoRecord contains non-early classes, and JVMTI
> // ClassFileLoadHook is enabled, it's possible for this class to be dynamically replaced. In
> // this case, we will not load the ArchivedKlassSubGraphInfoRecord and will clear its roots.
> 
> 
> However, this doesn't make sense for ArchivedBootLayer -- it's loaded in the early phase at runtime, so any classes referenced by ArchivedBootLayer will also be loaded in the early phase. This means JVMTI ClassLoadHook cannot replace SystemModuleReader.
> 
> Hence, the fix is simple -- for any classes referenced by the 3 "full-module-graph" subgraphs, we always treat them as "early" classes, regardless of when they are loaded during dump time.
> 
> 
> // Entry fields for subgraphs archived in the open archive heap region (full module graph).
> static ArchivableStaticFieldInfo fmg_open_archive_subgraph_entry_fields[] = {
>   {"jdk/internal/loader/ArchivedClassLoaders", "archivedClassLoaders"},
>   {"jdk/internal/module/ArchivedBootLayer", "archivedBootLayer"},
>   {"java/lang/Module$ArchivedData", "archivedData"},
> };
> 
> 
> The validate the fix, I modified the test case to always load CLDRLocaleDataMetaInfo during dump time. The test failed without the fix and passed with the fix.

Hi Ioi,

Based on your detailed description the fix seems quite reasonable.

Does this mean that when using CDS some classes are not subject to the application of the JVM TI ClassFileLoadHook? And if so, is that constraint documented somewhere?

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3780