Michael van der Gulik wrote:
> On 4/29/09, Igor Stasenko <siguctua at gmail.com> wrote:
>
>   
>> As for moving to multi-cores.. yes, as Gulik suggests, its like adding
>> a new dimension:
>>  - local scheduler for each core
>>  - single global scheduler for freezing everything
>>
>> This, of course, if we could afford running same object memory over
>> multiple cores. Handling interpreter/object memory state(s) with
>> multiple cores is not trivial thing.
>>     
>
> Implementing it isn't hard. It's fixing all the bugs we'll find that's
> hard. There'll be bugs in the image and in the VM, and it'll be a good
> 30 years before we've found them all.
>   

LOL, did I miss a smiley?  Doesn't sound trivial to me.

With great effort, I will avoid getting into another long thread about
how a Hydra-like model is more suitable to the memory architectures of
future multi-core processors (Nehalem is already splitting up the L2
between cores instead of making it uniformly accessible to all cores,
and this trend will continue).

(BTW, there is an ongoing discussion on GDAlgorithms
(gdalgorithms-list at lists.sourceforge.net) about task-parallel
multithreading architectures to take full advantage of multi-cores.  The
subject is "General purpose task parallel threading approach". 
C++-centric, but still interesting; game programmers do know how to eke
performance out of their hardware).

Cheers,
Josh


> *Most* parts of the VM will continue working fine. The parts that will
> break... er... some of the parts that will break are:
>
> * garbage collection.
> * allocating memory for new objects.
> * primitives and devices.
> * pointer swapping *might* need to be atomic (become:, becomeForward:).
> * Semaphore signalling.
> * (more things???)
>
> Most other things should work fine if we fire up a second interp() on
> another pthread which shares the same object memory.
>
> Writing to object slots (aka instance variables) should continue to
> work fine provided that the write itself occurs in a single atomic
> machine code instruction and that the object that the new reference
> points to is already allocated and initialized.
>
> Creating new objects could be improved by having each scheduler have
> it's own eden space. But then the garbage collection becomes more
> complex. The other alternative is to have a global image lock and
> whoever whines about it can implement a better solution.
>
> I think that's it. The only important thing shared between different
> OS threads (pthreads?) would be the object memory, and all you really
> do with the object memory is write or read from object slots, create
> new objects and run garbage collection.
>
> Also, it shouldn't always be necessary to freeze the entire image. If
> every scheduler has its own eden space and its own list of processes
> that nothing else is allowed to modify, then there's no need to freeze
> the whole VM for scheduler work. The only time the whole VM will need
> to freeze is for garbage collection, but even being very intelligent
> with a new GC design can avoid that.
>
> Gulik.
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090429/88b562bf/attachment.htm