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@f2f585 - lockMap size = 19050
sun.misc.Launcher$ExtClassLoader@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
