Proposal: Fully Concurrent ClassLoading (original) (raw)

Peter Levart peter.levart at gmail.com
Tue Dec 11 09:28:34 UTC 2012

Hi again,

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.

Regards, Peter

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

More information about the core-libs-dev mailing list