RFR: 8298469: Obsolete legacy parallel class loading workaround for non-parallel-capable class loaders [v2]

Coleen Phillimore coleenp at openjdk.org
Tue Mar 14 14:04:42 UTC 2023


On Tue, 14 Mar 2023 03:04:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The assertion reduces to something somewhat useless.  Without EnableWaitForParallel load, you can have more then one thread with a LOAD_INSTANCE placeholder.  These threads will wait when the go call into ClassLoader.loadClass() now.
>> There is nothing to assert here anymore.
>
> Okay. I confess I don't fully grok this part though.

The bootloader uses LOAD_INSTANCE to wait for other threads (JVM implementation of parallel capable class loading), but this function doesn't pass the class_loader so that would be the only useful modification to this assert.  But it seems too specific to actually catch any bugs.
Before this change with EnableWaitForParallelLoad, the non-parallel-capable class loader would wait on the LOAD_INSTANCE placeholder with double_lock_wait so there would never be more than one.  Now, both threads take out the placeholder, and are expected to wait in the ClassLoader.loadClass function.

>> Only the bootclass loader waits on the SystemDictionary_lock for multiple threads now.  Not the non-parallel capable class loaders.
>
> Got it. `must_wait_for_class_loading` implies boot-loader, so the original `return nullptr` is now handled outside the `if (must_wait_for_class_loading)`.

Yes.

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

PR: https://git.openjdk.org/jdk/pull/12974


More information about the hotspot-runtime-dev mailing list