Proposal: Fully Concurrent ClassLoading

[David Holmes]

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