2009/4/30 Michael van der Gulik <mikevdg at gmail.com>:
> 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???)
>

I love the *might*

What happens for example if you change a class definition... Say add
or remove an instance slot.
What would happen if the becomeForward on the array of instances and
subinstances and method dictionaries were not atomic?

Don't forget Smalltalk environment rely on such in vivo chirurgical operations.
You should better stop running while you or another thread is
replacing your own leg.

Of course, there is not a single solution. We could invent a world
where there is a compile phase and an execution phase...

Nicolas