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:
http://cr.openjdk.java.net/~alanb/6902010/webrev.00/
For testing, I've been using the tests in
test/java/lang/ClassLoader/deadlock.
Thanks,
Alan.
[1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45ff1a9d4edb
Hi Alan,
I think you can remove the intermediary synchronizedMap when creating
loaderTypes
and add a synchronized to isRegistered.
You should add a private constructor with no parameter that throw an
AssertionError
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.
Rémi
