Proposal: Fully Concurrent ClassLoading
david.holmes at oracle.com
Tue Dec 11 05:10:04 UTC 2012
FYI I've made some small updates to the blog entry.
Just to quantify the inefficiencies here is the instrumented output of a
simple test that tries to load all classes in rt.jar and prints out the
size of the lock maps:
18521 classes loaded.
sun.misc.Launcher$AppClassLoader at f2f585 - lockMap size = 19050
sun.misc.Launcher$ExtClassLoader at d5163a - lockMap size = 19050
You may be wondering about the 500+ difference between the loaded
classes and the map size? These represent classes in the list to load
that were not actually present in rt.jar. So as you can see you not only
get a lock object for every class successfully loaded, you get a lock
object for every class that is attempted to be loaded!
On 5/12/2012 9: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