[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Re: [feature] Add SMP support to VM
From: |
Paolo Bonzini |
Subject: |
[Help-smalltalk] Re: [feature] Add SMP support to VM |
Date: |
Wed, 10 Oct 2007 04:46:20 -0700 |
Issue status update for
http://smalltalk.gnu.org/project/issue/98
Post a follow up:
http://smalltalk.gnu.org/project/comments/add/98
Project: GNU Smalltalk
Version: <none>
Component: VM
Category: feature requests
Priority: normal
Assigned to: Unassigned
Reported by: sblinn
Updated by: bonzinip
-Status: active
+Status: postponed
It's not "impossible", and with OpenMP support in GCC it can actually be
done, I think. Not anytime soon, though. :-)
You could make the bytecode interpreter variables thread-local and put
the context switching into a critical section (i.e. only one kernel
thread could perform a green thread context switch, at a single time).
GC and object allocation could also be put in a critical section. If
you can make sure that message sends can be executed concurrently, that
would be great. I/O is not complicated, because it is already
asynchronous.
As I said, the easiest design would stop execution completely at GC
time. But *within* GC you can do some tricks. For new-space
collection, you could parallelize searching for roots in the grey
pages. Mark'n'sweep is slow, and at least the mark phase could be
parallelized.
So, there are a few small opportunities here and there besides the "big
thing".
Replying to Robin, who "wants to control which [] fork results in a
real and which in a pseudo-thread", I say that I disagree strongly; I'd
want M:N threading (where N is the number of kernel threads and M is the
number of green threads) instead.
That's because Smalltalk processes /are already pre-emptive/, though by
default there is no time-sharing. So, you need proper locking now too.
Suppose you have two processes P and Q modifying one variable. A third
one, R, has lower priority than the first two and is waiting on a Delay.
While P process is modifying the variable, the Delay fires, and the
high-priority timing process is woken up. This puts to sleep P and
sends it to the back of its ready-list. You guessed right: when the
timing process goes back to sleep, Q is at the beginning of its
ready-list, and it can see the variable in a half-modified status.