Proposal: Fully Concurrent ClassLoading

[David Holmes]

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
>