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

[Alan Bateman]

Valerie (Yu-Ching) Peng wrote:
> David,
>
> Thanks for the comments. I've updated the webrev accordingly at:
> http://cr.openjdk.java.net/~valeriep/7001933/webrev.01/
>
> 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 java.net.URL 
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