RFR: 8295673: Deprecate legacy parallel class loading workaround for non-parallel-capable class loaders

[David Holmes]

On Mon, 24 Oct 2022 12:16:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock.  The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete.  The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization.
> Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. 
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable()
> 
> Tested with tier1-6 and internal applications.

src/hotspot/share/runtime/globals.hpp line 683:

> 681:           "registering as parallel capable")                                \
> 682:                                                                             \
> 683:   product(bool, SynchronizeLoadClass, false, DIAGNOSTIC,                    \

I don't think the flag can be diagnostic. If people need to revert behaviour for their production systems then they will want a product level flag to use. This will need a CSR request anyway.

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

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