Hi,
> 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.
Yes. Making the ULR single threaded is an orthogonal issue (will make the ULR
simpler), but the real mechanism is to wait on the classloader, releasing its lock.
> 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.
Not sure I follow you.
The mechanism used now in ULR will do this:
- ULR.loadClass is single-threaded: only one thread at a time can load classes.
- All other threads that try to load classes concurrently are forced to wait on the
classloader they're asking the class, thus releasing its lock.
This should ensure that all threads have released the lock on the classloaders while
one loads classes. Or am I missing something ?
This is the intent; if it is possible to implement it is another story :)
I think it is, but maybe there are other (simpler) solutions.
> 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.
That's interesting.
It seems similar to the new mechanism where the ULR is doing the
"only-one-thread-at-a-time" filtering, but may result simpler.
I don't know if it carries other problems, but is worth a try.
> 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.
Which, even in case of fix for Jung's RFE - where one can override loadClass removing
the synchronized modifier - leads to the classloader being locked by JVM code, so it's
the same ol' story...
Cheers
Simon
_______________________________________________________________
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
