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 _______________________________________________ help-smalltalk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
