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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for 
http://smal
ltalk.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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Issue status update for 
http://smal
ltalk.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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Wed, Oct 10, 2007 at 04:46:20AM -0700, Paolo Bonzini
wrote:
> Issue status update for 
> http://smal
ltalk.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.

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
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk