Re: [Help-smalltalk] Re: [feature] Add SMP support to VM

[Robin Redeker]

On Wed, Oct 10, 2007 at 04:46:20AM -0700, Paolo Bonzini wrote:
> 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.

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