Code Review for 7001933: Deadlock in java.lang.classloader.getPackage()
Alan.Bateman at oracle.com
Sat Feb 26 09:40:33 UTC 2011
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