Hi,
> Are you sure?
No, I *think* so.
> From your desription it would seem that the reason
> loadClassInternal is syncronized is to stop this case from happening.
I think the main assumption of the JVM code is that noone waits during a
loadClassInternal() call on the classloader itself, thus releasing its lock. This is
what happens in JBoss classloaders. If someone does so, then the dictionary has a
placeholder, but the class is not loaded. If some other thread enters and ask for the
same class with the same classloader (and it can because the first one released the
lock on the classloader - it's waiting), then the CCE is thrown.
I have written a small test case that shows this problem without using JBoss'
classloaders.
It's a JDK bug or a feature ? ]:)
Simon
> The way you are describing it it would not make any differnce, and the
> resolve_instance_class_or_null is not thread safe.
>
>
> On Fri, 2002-05-31 at 12:13, Bordet, Simone wrote:
> > 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
>
>
>
> _______________________________________________________________
>
> 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
>
_______________________________________________________________
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
