Re: GNU Classpath 0.12, ..., 1.0

[Robert Lougher]

Hi all,

On Sat, 13 Nov 2004 11:58:53 +0100, Mark Wielaard <address@hidden> 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.