Proposal: Fully Concurrent ClassLoading

[Karen Kinnear]

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. 

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.

 "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.

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.

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/parallel_classloading_revisited_fully_concurrent
>>> 
>>> 
>> 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
>>