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.

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

-- 
http://gulik.pbwiki.com/