Lock contention in LaunchedURLClassLoader

[dreis2211]

Hey,

we recently noticed lock contention coming from the LaunchedURLClassLoader in two of our applications, which boils down to the following in Classloader:

   // This method is invoked by the virtual machine to load a class.
    private Class<?> loadClassInternal(String name)
        throws ClassNotFoundException
    {
        // For backward compatibility, explicitly lock on 'this' when
        // the current class loader is not parallel capable.
        if (parallelLockMap == null) {
            synchronized (this) {
                 return loadClass(name);
            }
        } else {
            return loadClass(name);
        }
    }

In case there is no parallelLockMap, it locks on the current instance of the classloader if it's not parallel capable. Which the LaunchedURLClassLoader unfortunately isn't, while its superclass URLClassLoader is. I wonder if there is a reason for that apart from the fact that this was introduced in 1.7 and might not be adopted yet. Setting the fast exception mechanism seems to go via a ThreadLocal variable already. Am I missing something that prohibits the use of the following?

	static {
		ClassLoader.registerAsParallelCapable();
	}

I appreciate any feedback or clarification.

Cheers,
Christoph

[wilkinsona]

Thanks for spotting this. LaunchedURLClassLoader was parallel capable, but it was lost in 87fe0b2#diff-dc50de280501378d899d1ca38e9877fc. We need to reinstate that logic.

[wilkinsona]

Thanks to the simplified delegation model, we don't need to mess around with the lock provider stuff. Simply registering as parallel capable should be sufficient. Closing in favour of #7334.