Ok, I'm not the expert on this stuff either, but in an effort to help out here is my explanation of what I think is happening.
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 loaders, let us say Thread A has locked ClassLoader A and Thread B has locked ClassLoader B. Now loadClassInternal simply calls the loadClass method of the respective class loader and so if you have a class loader (like the JBoss UnifiedClassLoader) which can delegate to other class loaders (via UnifiedLoaderRepository) to load classes you can get a situation where Thread A now wants to access synchronized methods in ClassLoader B and Thread B wants to access synchronized methods in ClassLoader A and neither can because of the earlier locks already gained, hence deadlock. This bought about by the fact that the private "loadClassInternal()" method is synchronized and can be called pretty much at any time by the JVM. The only way you could work around the problem is if you could synchronize on some common object before loadClassInternal is called, but since this is called rather unpredictably directly from the JVM I don't know if there is any way to do this. Why the F*K "loadClassInternal()" is synchronized is a complete mystery as all it does is call "loadClass()" which 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 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 and see that > |it needs to load also B. This is done at native level, and while a > |classloader is loading class A, the JVM calls loadClassInternal() > |on the *same* thread and on the *same* classloader to load class > |B; this may trigger another call and so on recursively. If the > > ok > > |classloader delegates to some other classloader you can have > deadlock. > > this I don't see, you seem to jump to the conclusion, can you > please walk > me? > > |There is a call for loadClass, some more call on java code, then a > |call to native method, and if the native method decides it has no > |sufficient information it calls back java code, it's java -> > |native -> java. > | > |loadClass() > | ... > | defineClass() [is this the native one ?] > | loadClassInternal() > | loadClass() > > So if loadClassInternal fails it goes to the "loadClass()" in > our stack? > > cl1.loadClass("A") > A refers to B > cl1.loadClassInternal("B") fails > cl1.loadClass("B") is then called. > > is that correct? > > And then ...? > > |A typical scenario for me was this one: jar1 with a set of related > |classes, and jar2 with another set, but the 2 jars interacts and > |are loaded by different classloaders. When something is "started" > |in jar1, not all classes in the jar are loaded; the "start" > |triggers loading from jar2 that happens to load some class from > |jar1 that was not already loaded. > > I am lost. > > Let's say > jar1:set1:cl1 has classes A and C > > jar2:set2:cl2 has class B > > A and B reference C > > A starts up loads A, loads class internal C (I assume it > finds it) but it is > not in the repository (internal call). > > In a mono threaded JBoss, B is loaded up by cl2.load("B"), > which doesn't > find it, starts up, needs to load C and so cl2.loadCint("B") > fails goes to > cl2.load(B) which goes repository.load(B) which then goes to > cl1.load(B) > which should work. > > Let's imagine a multithreaded JBoss where the service A > spawns a thread. > > please help > > marcf > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.350 / Virus Database: 196 - Release Date: 4/17/2002 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.350 / Virus Database: 196 - Release Date: 4/17/2002 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
