[sorry for cutting multiple Re's from the subject line]

On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:

> 2008/7/7 Klaus D. Witzel:
>> On Mon, 07 Jul 2008 10:49:06 +0200, Igor Stasenko wrote:
>>
>>> 2008/7/7 Andreas Raab :
>>>>
>>>> Peter William Lount wrote:
>>>>>
>>>>> Why prevent others from having their needed multiple native threads?
>>>>>
>>>>
>>>> It's not about preventing anything. If you have a proposal for how to  
>>>> do
>>>> multiple threads per image I will most definitely listen, and if it  
>>>> is a
>>>> reasonable proposal (i.e., one that can be implemented with bounded
>>>> resources) I will even try to find funding for it. However, until  
>>>> such a
>>>> time that there is a proposal I will drop this pointless discussion
>>>> since,
>>>> simply put, there is nothing to discuss here. The only available path  
>>>> at
>>>> this point is by using one native thread per image and consequently
>>>> that's
>>>> what's going to happen.
>>>>
>>>
>>> I have some ideas of using Island/Vat model in future CorruptVM  
>>> project.
>>>
>>> I'm not going into deep detail right now, but the essence of model is
>>> following:
>>>
>>> - an Island is the group of objects sharing same memory region.
>>
>> s/memory region/owner/ where owner can be sort of "deputy" of memory/VM
>> monitor. A very interesting concept indeed, thanks for posting :)
>>
>> I think that can be addressed with a small trick in Squeak's VM and *no*
>> extra object header (using one of the Metaclass ideas that Alex+my  
>> discussed in Bern for Goya => coloring of metaclass instances).
>>
>
> Yes, there is no need in having extra state which indicates to which
> island belongs object.
> It is impossible by design to get direct reference to any object which
> not belongs to same island.

I think that, "ref to any object" can be restricted to "any receiver",  
just so when sending something. When not sending something (=> when just  
peeking and poking oops) then belonging to some island is of not so much  
importance (this "receiver detail" is why I suggested s/memory  
region/owner/).

You agree? Of course the "any receiver" detail is relative to SqueakVM;  
CorruptVM's mileage may vary.

> For referencing objects from different island there will be a FarRef,
> which will be responsible for handling message sends to object in
> different island.

Hah :) a natural extension of the #doesNotUnderstand: concept (with  
FarMessageSend a subclass of MessageSend :)

>