RFR: 8265605: Cannot call BootLoader::loadClassOrNull before initPhase2 [v2]
Alan Bateman
alanb at openjdk.java.net
Wed May 12 18:49:18 UTC 2021
On Wed, 12 May 2021 18:23:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> This bug was discovered during the development of [JDK-6824466](https://bugs.openjdk.java.net/browse/JDK-6824466): when CDS is enabled, if `BootLoader::loadClassOrNull` is called before `initPhase2`, it would trigger the initialization of the archived module graph in the wrong order. Because of unanticipated nesting of `<clinit>` methods, `BootLoader::SERVICES_CATALOG` becomes empty, causing future `ServiceLoader` operations to fail.
>>
>> The fix has 2 parts:
>>
>> - `BootLoader::loadClassOrNull` no longer calls `ClassLoaders::bootLoader()`. This avoids triggering the archived module graph initialization. Instead, it makes a direct call to `Classloader::findBootstrapClassOrNull()`. We don't actually need a `ClassLoader` instance for this call, so I changed `Classloader::findBootstrapClassOrNull()` to be a static method.
>> - The object returned by `BootLoader::getServicesCatalog()` is now maintained inside `jdk.internal.loader.ClassLoaders`. Although not strictly required for the fix, this simplifies the initialization of the archived module graph. It also makes the logic consistent for the 3 built-in loaders (boot/platform/app).
>>
>> Testing: tiers1-4 in progress. I also verified that the bug reported by Mandy is no longer reproducible after I applied this patch on her branch.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>
> @AlanBateman comments
src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 60:
> 58: // Sets the ServicesCatalog for the specified loader using archived objects.
> 59: private static void setArchivedServicesCatalog(
> 60: ArchivedClassLoaders archivedClassLoaders, ClassLoader loader)
Thanks for the update. The formatting on L60 is messed now, can't the ArchivedClassLoaders go on the previous line? I don't have any other comments, it's worked out well.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3992
More information about the core-libs-dev
mailing list