@Lists. Sourceforge. Net
|Betreff: RE: [JBoss-dev] Workaround for CL stuff
|
|
|Solution:
|
|When a thread goes through loadClass, in the ULR we lock with a
|field that
|tracks the thread.
|
|Another thread comes in, reaches ULR, we sync on the calling CL
|(we know it)
|we wait, this releases the lock
2002 03:07
|An: Dave Smith
|Cc: lsanders; Jboss-Development@Lists. Sourceforge.
Net
|Betreff: RE: [JBoss-dev] Workaround for CL stuff
|
|
|Solution:
|
|When a thread goes through loadClass, in the ULR we
lock with a
|field that
|tracks the thread.
|
|Another thread comes in, reaches
fleury [mailto:[EMAIL PROTECTED]]
| |Gesendet: Dienstag, 23. April 2002 03:07
| |An: Dave Smith
| |Cc: lsanders; Jboss-Development@Lists. Sourceforge.
| Net
| |Betreff: RE: [JBoss-dev] Workaround for CL stuff
| |
| |
| |Solution:
| |
| |When a thread goes through loadClass, in the ULR we
| lock
I think one example is when you try to shut down jboss after running the
testsuite on jdk 1.4. At least this morning I got stuck and I'm pretty
sure there was a cl deadlock. It is not clear to me why shutdown would be
deadlocking here however. And this is not simple;-)
david jencks
On
Though I've never experienced this, I think this is the problem scenario:
The players:
UnifiedClassLoader A (can load directly class foo)
UnifiedClassLoader B (can load directly class bar)
Thread 1 (context loader is A):
Load new class bar:
- synchronize on UCL A
- Search UCL B
-
|The players:
|UnifiedClassLoader A (can load directly class foo)
|UnifiedClassLoader B (can load directly class bar)
|
|Thread 1 (context loader is A):
| Load new class bar:
|- synchronize on UCL A
|- Search UCL B
|- Attempt to synchronize on UCL B
|
|Thread 2 (contect loader is B):
Hi,
Where does the loadClassInternal() intervene?
It is called by the JVM when it has to resolve class dependencies.
Say you have class A that has a data member of class B.
When a CL is asked to load A, it inspects the class and see that it needs to load also
B. This is done at native level,
I brought this thing back to life and passed the URL of the orginal sun
bug that they rejected. Here is a quick stack trace of the deadlock.
Note that you should start jboss with the -Xdebug options so it shows
you what objects that it is trying to lock. See below for my orginal
post
CCRAPoll
: Monday, April 22, 2002 12:27 PM
|To: Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Workaround for CL stuff
|
|
|Hi,
|
| Where does the loadClassInternal() intervene?
|
|It is called by the JVM when it has to resolve class dependencies.
|
|Say you have class A that has a data
Simone,
I still don't see the problem clearly, please help me.
| Where does the loadClassInternal() intervene?
|
|It is called by the JVM when it has to resolve class dependencies.
ok
|Say you have class A that has a data member of class B.
|When a CL is asked to load A, it inspects the class
can be synchronized if it needs to
be.
David
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 23, 2002 8:47 AM
To: Bordet, Simone; Jboss-Development@Lists. Sourceforge. Net
Subject: RE: [JBoss-dev] Workaround for CL stuff
Simone,
I still
thanks this is useful
marcf
|-Original Message-
|From: Dave Smith [mailto:[EMAIL PROTECTED]]
|Sent: Monday, April 22, 2002 12:49 PM
|To: marc fleury
|Cc: lsanders; Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Workaround for CL stuff
|
|
|I brought this thing back
this...
thanks for the input guys
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of David
|Maplesden
|Sent: Monday, April 22, 2002 2:36 PM
|To: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Workaround for CL stuff
|
|
|Ok
Hi Marc,
Simone,
I still don't see the problem clearly, please help me.
Will try to do my best. I used the now old (thanks to you) classloader delegation
model in my project, so you probably have to integrate me with the JBoss stuff
(correct me if I'm wrong) :)
|classloader delegates to
Hi,
The major problem (and the starting point of the whole thing)
is that when
classes are being loaded the JVM can call
loadClassInternal() on multiple
class loaders at the same time. This method is synchronized and so
immediately two different threads have locked two different
class
|You have 2 threads, both waiting for something, just started, so
|not classes have been loaded yet. (see Dave Smith post for stack
|trace and example).
|Thread CCRAPoll (call it Encryption thread) asks the CtxCL to
|load something. CtxCL is some JBoss UCL.
|Other thread is Thread-20 (call it
PM
To: David Maplesden; Jboss-Development@Lists. Sourceforge. Net
Subject: RE: [JBoss-dev] Workaround for CL stuff
Ok...
I think I see,
but then there might be a solution which is to sleep one of the thread
which will release the lock for that we need detection at the ULR level
of usage wich we
|Also ClassLoader.loadClass(String, boolean) is sync'ed. It's not a
|problem of loadClassInternal IMHO.
|Also the UCL at the end calls super.loadClass() (in
|loadClassLocally()) so...
right so it is just a problem with synchronized cls...
I will try the solution I am thinking of.
hey quick
Solution:
When a thread goes through loadClass, in the ULR we lock with a field that
tracks the thread.
Another thread comes in, reaches ULR, we sync on the calling CL (we know it)
we wait, this releases the lock, we keep track of the CL as part of this
load. The first thread will always find
19 matches
Mail list logo
