Hi,
so I dug into the hotspot code for JDK 131, and I found the problem. I am too tired
now to think for a solution, this is for you brave guys :)
The problems arises from a 20 lines of code in
src/share/vm/memory/systemDictionary.cpp (attached), method
resolve_instance_class_or_null(...).
The loading mechanism of the JVM is done in 2 steps:
1- look in a dictionary, if not found, put there a placeholder, then
2- load the class, calling loadClassInternal().
Thread A comes in asking for class "cls1" with classloader cl1, the class has never
been loaded, put a placeholder in the dictionary, and call loadClassInternal.
Thread B comes in asking for class "cls1" with classloader cl1, there is already a
placeholder, throw CCE.
The key is to ask for the same class with the same classloader.
I think this may happen with the UnifiedClassLoader scheme in several occasions, a
simple example being:
class Base {}
class Derived1 extends Base {}
class Derived2 extends Base {}
If Base is loaded by classloader1, and we have 2 threads trying to load one Derived1
and one Derived2 (and both need Base), we end up with 2 thread using the same
classloader to load the same class, and the JVM code throws CCE.
I wrote a simple testcase (attached), but it does not use JBoss classloaders, however
should be trivial to code it against JBoss codebase. If someone can take care of it...
thanks :P
As I said I did not think enough to find a solution, but at least we all know where to
start.
Cheers
Simon
PS: it seems attachments are not allowed ?
_______________________________________________________________
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
