Hi all, On Sat, 13 Nov 2004 11:58:53 +0100, Mark Wielaard <[EMAIL PROTECTED]> wrote: > The Eclipse 3 (but not 2) startup problem seems to only happen on SMP > machine (it disappears when I don't use a SMP kernel, this is on a Intel > hyperthreading system) with jamvm [*]. It works fine with gcj/gij (it > doesn't work anymore with kaffe though since they don't implement > java.lang.ClassLoader.setSigners which we now call).
I'm not terribly surprised -- I've never tested JamVM on a real or virtual SMP machine before. When writing the thin-locking implementation I didn't include any SMP memory barriers, so it's something I've been expecting to hear! I'll look at including them for the next release. Mark, would you be willing to do the testing? > Cheers, > > Mark > > [*] Hint for Robert. When inspecting with -verbose I can see that some > classes are [loaded] multiple times. I can slow down crashing a bit by > making various VMClass static methods synchronized, but that is not a > full solution. I think this is a bug in the runtime that needs to guard > against defining the same class from multiple threads and not completely > fixable in our core libraries setup. > I don't think this is the cause. This can happen even on a uni-processor machine. Two threads can see a class hasn't been loaded and start to define it. However, the updating of the loaded class hash table is locked. One thread will win the race and update the table, the other will find it already there, and discard the one it's just loaded. This keeps locking to a minimum, and should lead to overall faster behaviour. It's a bug as to where the -verbose message is printed -- it should only be done by the thread that wins the race. Rob. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
