[feature] Add SMP support to VM

Issue status update for
http://smalltalk.gnu.org/node/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:   sblinn
 Status:       active

I'm sure this is very non-trivial, but adding SMP support to GST's VM
would have the potential to greatly improve the performance of
multi-process servers written for GNU Smalltalk.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

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:   elmex
 Status:       active

Here are some of my mostly random thoughts about this:

Yes, this seems to be highly non-trivial to me.
But in times of multi-core CPUs popping up everywhere
(even under my desk), it would certainly make GNU
smalltalk even more interesting.

But I guess there will be big issues with the GC
and the I/O subsystem.

I also wonder how the API would look like on the
smalltalk side. Can I specify which thread is a
"real" thread? What kind of locking can I use?

Will the VM crash on me when I write to an object
at the same time? Are there alternatives?

My opinion is that locking and synchronizing should
be up to the Programmer. Thread programming and
synchronization is a very complicated thing and there
is afaik no easy way out. Let the programmer decide
wheter he needs real threads and when he needs
synchronization.

I just wanted to say that IF I get real threads somehow
in smalltalk, I want to control which [] fork results
in a real and which in a pseudo-thread. And that
if I mutate an object in two "real" threads at the same
time (without locking) I deserve a segfault and core dump
or corrupted data.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

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.




_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, Oct 10, 2007 at 04:46:20AM -0700, Paolo Bonzini wrote:
Stopping the world for GC would be quite ugly and bad for high
performance network applications. But maybe smalltalk or such a GC
is maybe in general not the best solution for that :)

> So, there are a few small opportunities here and there besides the "big
> thing".

Hm, the only benefit would be that computing intensive things can be
pushed to other threads which then can be distributed by the kernel to
other processors.

> 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.

Hm, I basically meant that I would like to have control which threads
are real and which not. But if my process can already be interrupted
at any time, then I guess it doesn't make much difference.

> That's because Smalltalk processes /are already pre-emptive/, though by
> default there is no time-sharing.  So, you need proper locking now too.

Oh, ok, missed that completly. I though of those threads more as
cooperative threads similar to coroutines, and I didn't know the
term 'per-emptive' yet, so sorry for talking nonsense there :)

The more I think about it, the more I would love to have non-preemptive
threads where I have a bit more control who messes with my data :)


Robin


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

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:   MrGwen
-Status:       postponed
+Status:       active

You can take a look there
https://github.com/MrGwen/GNU-Smalltalk/tree/process
that's a bit different to what you propose, here I load multiple
kernels and images
in a separate vm thead:

w := World bootstrap: 'kernel/'. " will be the path of you kernel "
w := Worl load: 'gst.im'. " will be the path of you image "
w send: #Foo with: 1 with: 2. " for sending a message to the remote
image "



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk