[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chris Pickett
Subject: Re: SMP problems (was Re: GNU Classpath 0.12, ..., 1.0)
Date: Sat, 13 Nov 2004 12:09:57 -0500
User-agent: Mozilla Thunderbird 0.6 (X11/20040509)

sorry, please CC responses to that last message to


instead of



Chris Pickett wrote:
Robert Lougher wrote:

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?



[*] 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).


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]