Proposal: Fully Concurrent ClassLoading
peter.levart at gmail.com
Tue Dec 11 09:28:34 UTC 2012
There might be a middle-ground variant. No registration API changes as
described below. When ClassLoader X declares that it is fully-concurrent
make it fully-concurrent. But if any superclass registered as only
parallel-capable, provide getClassLoadingLock() locks nevertheless. Only
if all the superclasses declare that they are fully-concurrent, make no
lock map and make getClassLoadingLock() return null.
On 12/11/2012 10:20 AM, 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
> 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.
> 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
> 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
More information about the core-libs-dev