Need reviewer for 6902010: (cl) Delay initialization of ClassLoader.parallelLoaders
Valerie Peng
Yu-Ching.Peng at Sun.COM
Thu Nov 19 02:25:04 UTC 2009
Changes look fine to me as well.
BTW, I normally run all regression tests under "java/lang
java/net/URLClassLoader sun/applet/AppletClassLoader" for classloader
related changes.
Thanks,
Valerie
On 11/18/09 09:19, Mandy Chung wrote:
> Looks good. I reviewed your latest webrev that incorporated Rémi's
> suggestion.
>
> Mandy
>
> Alan Bateman wrote:
>> 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
>>
>>
>
More information about the core-libs-dev
mailing list