Code Review for 7001933: Deadlock in java.lang.classloader.getPackage()

Valerie (Yu-Ching) Peng valerie.peng at
Tue Mar 8 01:08:19 UTC 2011

It could be that they have custom classloader which isn't parallel 
capable. So, this will still occur w/ jdk7 if this is the case.
We'll need to get some more information on the setup to reproduce the 
issue. Given the time constraint, I'll file a bug to keep track of this 
test case creation, but this will likely not be done for jdk7.

Thanks for all the comments/feedbacks,

On 02/26/11 01:40 AM, Alan Bateman wrote:
> Valerie (Yu-Ching) Peng wrote:
>> David,
>> Thanks for the comments. I've updated the webrev accordingly at:
>> In the case of a race condition, we'll just return the earlier 
>> defined package object, i.e. pkg2 in your code sample.
>> Or, we could also get rid of this code block altogether, then there 
>> shouldn't be a race condition. However, this means that we'll  call 
>> into the parent loader for the packages that they defined which 
>> implies some performance cost.
> I think the updated changes are okay/harmless but it's not completely 
> clear to me that the specific deadlock that this bug is about can 
> actually happen in jdk7 (because AppClassLoader is parallel capable).
> It would be great to put in time to develop a test to demonstrate the 
> original issue, even if can't be an automated regression test (I've no 
> doubt that it would need to run many iterations to duplicate).
> I also think we should submit a bug to re-examine how 
> behaves when java.protocol.handler.pkgs is set. Minimally I think it 
> needs to be clearer on the initiating loaders used when attempting to 
> load the protocol handler. In addition it's not clear to me that it 
> should fallback to the system class loader for the "file" protocol 
> handler as that is required early in the startup to define the system 
> package.
> -Alan

More information about the core-libs-dev mailing list