Proposal: Fully Concurrent ClassLoading (original) (raw)

David Holmes david.holmes at oracle.com
Tue Dec 11 02:55:24 UTC 2012

Hi Karen,

Thanks for your feedback.

On 11/12/2012 12:31 PM, Karen Kinnear wrote:

David,

I fully support the concept of a fully concurrent class loader, which allows parallel defineClass. I would agree that we deprecate registerAsParallelCapable - starting deprecation in JDK8.

Okay that seems to be the consensus. I'm obviously way too conservative :)

My memory is that customers asked us for the getClassLoadingLock API so that they could do their own internal concurrency controls using the same lock we created, so I think we need the blog etc. to explicitly ask for feedback on having this API return NULL or deprecating it. It does matter if our customers are using the results.

Okay it would be good to understand this better. Given each parallel classloader had a different lock per class this really only matters if they try to get the lock used by one of the existing system classloaders. Their own parallel loaders will continue to function as normal.

"Fully concurrent" means custom class loaders that need to protect any per-class data do their own internal locking, not that no locks are needed. It means we allow concurrent defineClass, with the defineClassIfNotPresent semantics.

Is that a question or a statement? :) A fully concurrent loader needs no 'framework' support for synchronizing classloading. That could be because it uses its own locks, or that no locks are needed.

Question on the source code: registerAsFullyConcurrent has confusing comment - do the super classes all need to be parallel capable? Or do the super classes all need to be FullyConcurrent? I assume the latter, so just fix the comments.

Actually it is the former. There's no reason to require that all superclasses be fully-concurrent. Of course a given loaders degree of concurrency may be constrained by what it's supertype allows, but there's no reason to actually force all the supertypes to be fully-concurrent: it is enough that they are at least all parallel capable.

Thanks, David

thanks, Karen

On Dec 9, 2012, at 11:08 PM, David Holmes wrote:

Thanks for the comments Mandy. On 8/12/2012 9:46 AM, Mandy Chung wrote: On 12/5/12 3:59 AM, David Holmes wrote: Java 7 introduced support for parallel classloading by adding to each class loader a ConcurrentHashMap, referenced through a new field, parallelLockMap. This contains a mapping from class names to Objects to use as a classloading lock for that class name. This scheme has a number of inefficiencies. To address this we propose for Java 8 the notion of a fully concurrent classloader ...

This is a fairly simple proposal that I've written up as a blog entry: https://blogs.oracle.com/dholmes/entry/parallelclassloadingrevisitedfullyconcurrent

It's a good and simple proposal and also handles the backward compatibility nicely. I think having getClassLoadingLock() to return null for a fully concurrent loader is a good idea. In case if any code synchronizes on the returned value after migrating to fully concurrent class loader, it will catch such usage (it might be very rare)/ The only glitch with this is that a concurrent loader is-a parallel loader, so anyone trying work with an arbitrary parallel loader will encounter a problem with a concurrent loader if they don't make their code concurrent-loader aware. I am hopeful that the parallelLockMap is only being used internally by the classloaders themselves, and that there are no, or very few, external clients. I agree with Alan's suggestion - we should consider deprecating registerAsParallelCapable. Definitely a consideration, though as I said perhaps for 9 rather than 8. Thanks, David Mandy

More information about the core-libs-dev mailing list