JDK-4670071 : java.lang.ClassLoader.loadClassInternal(String) is too restrictive
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_8,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 2002-04-17
  • Updated: 2022-10-13
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u18Fixed 7 b47Fixed hs15Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Name: nt126004			Date: 04/17/2002

java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)


Microsoft Windows 2000 [Version 5.00.2195]

Under Bug Id  4406709, someone has recently
(unsuccessfully) filed a bug wrt the "private synchronized"
modifiers of the method

java.lang.ClassLoader.loadClassInternal(String name)
	throws ClassNotFoundException;

leading to deadlocks in his derived special-purpose

The bug has been closed because of not being a violation
against the spec. That is perfectly true.
However, I want to reissue that topic here, but this time
under the "Ease of Use" or rather "Huge Amount of Fantastic
Possibilities" category.

In JBoss3.0 (http://www.jboss.org), we have - or rather
Marc Fleury has - quite successfully experimented with a
non-tree-based, runtime-dependency-checking classloader
delegation model that has a lot of nice modularity and hot-
deploy features. These features cannot be reached by
the "traditional" tree model.
In that model, as opposed to the tree model, it is
legal to dispatch a loadClass(String name) call to
another classloader that is NOT a parent of
the initiating classloader that is, e.g., trying to
satisfy a link.

Depending on the topology of the classloader graph,
deadlocks as caused by  non-interceptible
loadClassInternal calls are hence likely to occur if not
countermeasures are taken (e.g., restricted threading while
accessing the classloaders). Since there is no safe way to do
that, spurious deadlocks still happen.
Delegating to separate objects that are not affected by
the classloaders locks as proposed by one of the SUN
engineers in response to the previously filed bug is not
possible, because we have to re-delegate to
other -potentially locked- classloaders in the end.

You see that I?m deeply disappointed with the current
resolution of this issue. I hope you understand the huge
possibilities that appear when relaxing the current
solution. Having loadClass() synchronized or
loadClassInternal() protected should IMHO suffice to meet
the specification requirements, shouldn?t it?

I know that I am maybe not in the situation to sufficiently
motivate or explain the issue, but I know that it is a
highly important piece of the VM!

I hope that other (more involved) people can add comments
with code to back-up this request more appropriately than I
am able to do.
(Review ID: 145293) 

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c81d2ef51ca3

EVALUATION Changes for the VM side of this fix will be added to the VM under 4670071. Changes to the class libraries under 4735126. The changes include a new API for class loaders that can support parallel class loading. This implies that custom class loaders that want to take advantage of the new parallel class loading which avoids deadlocks, must make code changes. Existing class loaders will continue to work as they do now, unchanged.

EVALUATION We have finally completed the underlying engineering changes required in the JVM to allow us to prototype API modifications. We are posting a Draft Proposal of these class loader API changes at: http:dcstaff.invokedynamic.info/index.php?title=Image:classloaderproposal.tgz We invite you to read and review this proposal and provide us with feedback. Our goal is to make a prototype available in mid December 2008 after incorporating initial feedback. I apologize for how long this has taken. I have been working on the underlying changes to the VM logic to support loading multiple classes in parallel without deadlocking: JDK6: fixed class circularity bug Hotspot 10: JDK 6u4: Modified VM common class resolution logic to handle parallel class loading A pointer to the updated proposal will be available on http://openjdk.java.net/groups/core-libs Please join the conversation on the ###@###.### mailing alias. See http://mail.openjdk.java.net/mailman/listinfo to join the alias.

EVALUATION ###@###.### 2002-05-28 We will revisit this decision (from bug 4406709). ###@###.### 2002-06-20 This needs to be considered a valid bug - the classloader objects cannot remain locked, as demonstrated in bug 4699981, where a ClassCircularityError is thrown. This is due to the VM being confused about which thread is loading which class when the classloader lock got given up by a user classloader. Since the user can give up the classloader lock, we can't guarantee that the lock holds, we should not depend on the lock. The test case in 4699981 should be used here. ------------------------------------------------------------ This work is targetted for Dolphin. This will take a number of steps, some of which are already in progress, but the overall effort will take until Dolphin to complete. This will require a level of rearchitecture of classloading, and due to backward compatibility constraints will probably result in additional APIs. We very much appreciate the testcase, and any additional test cases customers wish to provide, so that we are sure that the improvements solve the problems they are intended to solve. It is my hope that we also work closely with those who have reported or added their names to this report to ensure that the new design and implementations meet all the needs we possibly can. Specific steps being taken to resolve this issue: 1) 4699981 class circularity detection fixes - Mustang 2) - redesign vm internal locking mechanism and granularity so as not to use classloader object for internal locking - ensure vm classloading logic is MT-safe 3) - design/implement new classloading apis in libraries 4) 4670071 - vm support for new classloading apis Clearly some of these steps are being done in parallel, but this can help outline the changes needed. One of the biggest challenges technically is backward compatibility. Despite the issue that we need to change this since it does not match the classloading model for quite a number of customers, we also need to ensure that the old apis continue to give the same behavior they have now. One way customers could assist with this is any contributions of test cases for current classloading behavior that applications are counting on that we need to ensure do not break. We very much look forward to working closely with the community in both the design and testing of the new apis as well as in helping us to ensure that current applications continue to run well. ###@###.### 2005-04-25 14:06:57 GMT ###@###.### 2005-04-27 12:56:48 GMT

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang