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.
Thanks,
David
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:
https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
Please discuss this proposal here.
Thanks,
David Holmes
