Code Review for 7001933: Deadlock in java.lang.classloader.getPackage()
Valerie (Yu-Ching) Peng
valerie.peng at oracle.com
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:
>> 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 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
More information about the core-libs-dev