Proposal: Fully Concurrent ClassLoading

David Holmes david.holmes at
Mon Dec 10 03:53:21 UTC 2012

Hi Peter,

I think your middle-ground sounds like it may have been a better choice 
for JDK 7. But for this proposal I want to try and leave parallel 
loaders behind and move to the fully concurrent model.

The real crux of my proposal is how often you really do get concurrent 
load attempts and so waste effort doing concurrent findClass for the 
same class. Obviously you can easily construct the pathological 
microbenchmark for this, but I'd like to base this on real experiences.

The question then is whether some additional flow-control can be added 
to the fully concurrent model, if it proves necessary.


On 6/12/2012 9:32 PM, Peter Levart wrote:
> Hi David,
> What about a middle-ground mode where findLoadedClass() and delegation
> to parent would be called without locks and only findClass() would be
> guarded by a per-class-name-per-classloader lock? In this mode
> concurrent attempts to define the same class would still be possible,
> but the possibility would be much lower. Usually findClass() involves
> non-ignorable level of resource-intensive work (ZIP, IO, NET) before it
> calls defineClass()...
> Also, in this mode, the Map of locks could be implemented so that lock
> objects would be Weak(ly)Reference(d), since requests for already loaded
> classes would be satisfied by findLoadedClass() already. We'd just need
> a ConcurrentWeakValuesHashMap.
> There must be something I'm missing here, isn't it?
> Regards, Peter
> On 12/05/2012 12:59 PM, 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:
>> Please discuss this proposal here.
>> Thanks,
>> David Holmes

More information about the core-libs-dev mailing list