Proposal: Fully Concurrent ClassLoading
david.holmes at oracle.com
Mon Dec 10 03:53:21 UTC 2012
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.
>> David Holmes
More information about the core-libs-dev