Proposal: Fully Concurrent ClassLoading

[Peter Levart]

On 12/11/2012 10:29 AM, David Holmes wrote:
> On 11/12/2012 7:20 PM, Peter Levart wrote:
>> On 12/11/2012 03:55 AM, David Holmes wrote:
>>>> 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.
>>
>> Hi David,
>>
>> There is one caveat: if ClassLoader X declares that it is
>> fully-concurrent and it's superclass Y is only parallel-capable, then X
>> will act as fully-concurrent (returning null from
>> getClassLoadingLock()). superclass Y might or might not be coded to use
>> the getClassLoadingLock(). X therefore has to know how Y is coded. To be
>> defensive, X could ask for Y's registration and declare itself as only
>> parallel-capable if Y declares the same so that when Y is upgraded to be
>> fully-concurrent, X would become fully-concurrent automatically. To
>> support situations where the same version of X would work in two
>> environments where in one Y is only parallel-capable and in the other Y
>> is fully-concurrent, there could be a static API to retrieve the
>> registrations of superclasses.
>
> I don't quite follow this. What code in the superclass are you 
> anticipating that the subclass will use which relies on the lock? Or 
> is this just an abstract "what if" scenario?

This is more or less "what if". There might be a subclass Y of say 
java.lang.ClassLoader that overrides loadClass or findClass, declares 
that it is parallel-capable and in the implementation of it's loadClass 
or findClass, uses getClassLoadingLock() to synchronize access to it's 
internal state. Now there comes class X extends Y that declares that it 
is fully-concurrent. Of course this will not work, X has to declare that 
it is parallel-capable, because Y uses getClassLoadingLock().

What I suggested in the next message is to not change the registration 
API but rather provide getClassLoadingLock() that returns non-null locks 
when any of the superclasses declare that they are only 
parallel-capable, not fully-concurrent.

Regards, Peter

>
> Thanks,
> David
> -----
>
>> Or, to have less impact on future deprecation of old parallel-capable
>> registration API, the fully-concurrent registration API:
>>
>> protected static boolean registerAsFullyConcurrent()
>>
>> might take a boolean parameter:
>>
>> protected static boolean registerAsFullyConcurrent(boolean
>> downgradeToPrallelCapableIfAnySuperclassIsNotFullyConcurrent)
>>
>>
>> and provide no accessible API to find out what the registration actually
>> did (register as parallel-capable or fully-concurrent - return true in
>> any case).
>>
>> Since all JDK provided ClassLoaders will be made fully concurrent, this
>> might only be relevant if there is vendor A that currently provides only
>> parallel-capable ClassLoader implementation and there is vendor B that
>> subclasses A's loader and wants to upgrade and be backward compatible at
>> the same time.
>>
>> Does this complicate things to much for no real benefit?
>>
>> Regards, Peter
>>