I don't see how we can guarentee that there will not be deadlocks
by focusing on making the ULR single threaded since that is not
the point of locking that we do not have control over. The issue
is the loadClassInternal class call initiated by the VM and my
concern is illustrated by this stack trace from a ULR version
prior to Simone's rewrite:
at java.lang.ClassLoader.loadClass(ClassLoader.java:283)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.
java:234)
at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito
ry.java:183)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:27
8)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
* at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
- locked <2ed1db8> (a org.jboss.mx.loading.UnifiedClassLoader)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:488)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:243)
at java.net.URLClassLoader.access$100(URLClassLoader.java:51)
at java.net.URLClassLoader$1.run(URLClassLoader.java:190)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
at
org.jboss.mx.loading.UnifiedClassLoader.findClass(UnifiedClassLoader.java:22
6)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.
java:234)
at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderReposito
ry.java:161)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:27
8)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
+ at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
- locked <2ed1db8> (a org.jboss.mx.loading.UnifiedClassLoader)
at
org.apache.catalina.core.ApplicationContext.getRequestDispatcher(Application
Context.java:607)
The potential problem here is the native method defineClass0 which invokes
loadClassInternal(*). In this case it happens to be the same class loader
that starts the trace at loadClassInternal(+). If however, it was a
different class loader that another thread happened to have called
loadClassInternal, that needs this class loader, there is nothing that
can be done to avoid the deadlock using the instances that the threads
have access to. What is not clear is if this situation can happen. Looking
at the VM native code for defineClass0 the call to loadClassInternal is
occurring to load the first classes super classes. Certainly the
superclasses
may only be available from another class loader.
One solution is to have the public UCLs be simple facades over the actual
UCL2s that sit in the ULR and perform the actual class loading. On entry
into a UCL.loadClass() method, a simple singleton lock can be used to
ensure that only one thread is able to interact with the UCL2s in the
repository. Since we control the thread accessing the UCL2s there cannot
be but a single thread invoking the syncrhonized loadClassInternal method
and
it does not matter how many other UCL2s loadClassInternal are invoked in
the process of resolving the requested class.
As a side note there is this comment in code that makes up defineClass0
"javavm/runtime/classresolver.c" line 2074
if (loader) {
/* Although class loaders are supposed to define loadClass as
* a synchronized method, the VM does not trust the class loader
* to do so. It enters the loader monitor just in case.
*/
monitorEnter2(ee, obj_monitor(loader));
} else {
SYSLOADER_LOCK(self);
}
so it would seem the class loader mutex is going to be acquired by
the VM somewhere other than loadInternalClass.
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
