Proposal: Fully Concurrent ClassLoading

[David Holmes]

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!

David
-----

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