RFR: 8342303: Segfault in update_inherited_vtable: AppCDS, old bytecode, and redefineClasses [v3]
Calvin Cheung
ccheung at openjdk.org
Wed Oct 30 21:58:02 UTC 2024
On Wed, 30 Oct 2024 02:34:10 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> In this case, the `getContextClassLoader()` is default to the AppClassLoader.
>> I added some println in the test:
>>
>> System.out.println(" ClassLoader " + Thread.currentThread().getContextClassLoader());
>> Class superCls = Thread.currentThread().getContextClassLoader().loadClass("OldSuper");
>> System.out.println("OldSuper>> loader = " + superCls.getClassLoader());
>>
>>
>> below is the output:
>>
>> ClassLoader jdk.internal.loader.ClassLoaders$AppClassLoader at 5451c3a8
>> OldSuper>> loader = jdk.internal.loader.ClassLoaders$AppClassLoader at 5451c3a8
>>
>> If the class is in the boot class path, then the class should be loaded by the boot class loader.
>
> You kind of avoided the question though - why are you using the context classloader instead of e.g the classloader of the current class? The CCL is defined as follows:
>
>> Returns the context ClassLoader for this thread. The context ClassLoader may be set by the creator of the thread for use by code running in this thread when loading classes and resources. If not [set](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Thread.html#setContextClassLoader(java.lang.ClassLoader)), the default is to inherit the context class loader from the parent thread.
>>
>> The context ClassLoader of the primordial thread is typically set to the class loader used to load the application.
>
> So if nothing sets it then you are just using the App/System loader, so why not just use that loader directly?
I've updated the tests to avoid using `getContextClassLoader()loadClass()`.
For the App/System loader case:
`ClassLoader.getSystemClassLoader().loadClass()`
For the boot loader case:
`Class.forName(<class name>, false, null)`
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21667#discussion_r1823445805
More information about the hotspot-runtime-dev
mailing list