Need reviewer for 6902010: (cl) Delay initialization of ClassLoader.parallelLoaders

Rémi Forax forax at
Tue Nov 17 19:22:05 UTC 2009

Le 17/11/2009 19:04, Alan Bateman a écrit :
> Valerie,
> I'd like to re-visit the initialization of the parallel-capable 
> loaders [1]. Currently the set of parallel-capable loader types is 
> created by ClassLoader's initializer. That works today but is a bit 
> fragile in that any changes or fixes that cause ClassLoader to be 
> initialized earlier in the VM startup could cause problems. For 
> example, if ClassLoader were to be initialized earlier then adding the 
> initial element will cause a weak reference to be created and that 
> will NPE in the Reference's initializer as the main thread isn't in a 
> thread group at that point. All code that executes before the system 
> classes are fully initialized requires great care so for this one, I 
> think the simplest thing would be to delay the initialization unless 
> the first loader is created. Does that seem reasonable? I've put a 
> webrev with the proposed changes here:
> For testing, I've been using the tests in 
> test/java/lang/ClassLoader/deadlock.
> Thanks,
> Alan.
> [1]

Hi Alan,
I think you can remove the intermediary synchronizedMap when creating 
and add a synchronized to isRegistered.

You should add a private constructor with no parameter that throw an 
because this class is not intended to be instantiated.
(you need the AssertionError because a private constructor can be called 
from enclosing class).

Moreover, I don't think it's a good idea to synchronized on the class 
(here ParallelLoaders.class)
because this object is public, by example you can get a reference to it 
using a java agent.
I would prefer a synchronized block on loaderTypes.


More information about the core-libs-dev mailing list