United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4670071 java.lang.ClassLoader.loadClassInternal(String) is too restrictive
JDK-4670071 : java.lang.ClassLoader.loadClassInternal(String) is too restrictive

Details
Type:
Bug
Submit Date:
2002-04-17
Status:
Closed
Updated Date:
2010-07-09
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
solaris_8,generic,windows_2000
Sub-Component:
runtime
CPU:
x86,sparc,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
Name: nt126004			Date: 04/17/2002


FULL PRODUCT VERSION :
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)

FULL OPERATING SYSTEM VERSION :

Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
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
classloaders.

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) 
======================================================================

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-10-02
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
                                     
2005-04-25
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.
                                     
2008-11-13
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.
                                     
2008-12-19
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c81d2ef51ca3
                                     
2009-01-06



Hardware and Software, Engineered to Work Together