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