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

[Valerie (Yu-Ching) Peng]

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,
Valerie

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:
>> 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