SMP problems (was Re: GNU Classpath 0.12, ..., 1.0)

Robert Lougher wrote:
> 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.


For what it's worth, we've had SMP problems in SableVM for a while now
also.  They too seem related to thread startup and thread death.  It
never occurred to me that this might be a Classpath problem since until
now I thought we were the only ones, but then again it could just be
that both JamVM and SableVM have equally bad internal locking :(.  I
tried putting in memory barriers as prescribed by the JSR133 cookbook
[1], but it didn't make any difference.  In fact, I tried putting a
StoreLoad barrier in between every single bytecode instruction, and it
still didn't help.  I haven't tested Eclipse, but will try to (or some
other SableVM person with a working Eclipse installation could try).

[1] http://gee.cs.oswego.edu/dl/jmm/cookbook.html

SableVM also doesn't have any handling of Java volatiles, which do
indeed exist in the Classpath threading code.  However, one would think
that with a barrier in between every single bytecode that this wouldn't
matter and that something else must be wrong.  We did manage to squash a
couple of threading bugs when somebody tried to build on NetBSD (I
think...), and got compile-time pthread initialization warnings.

Again my experience says that this isn't strictly limited to SMP
machines, but that on UP's the time between context switches is so long
that it's much harder to catch these heisenbugs.

I think it would be interesting to hear from VM developers who _don't_
have problems on SMP machines but had them in the past and somehow
managed to eliminate them.

Chris


P.S.  Originally sent to [email protected] with a CC to 
[email protected] by mistake.  Please respond to 
[email protected], [email protected], [email protected], and 
[email protected].  Thanks.