[squeak-dev] Re: Prepare for Thousands of Cores --- oh my Chip - it's full of cores!

Klaus D. Witzel klaus.witzel at cobss.com
Mon Jul 7 14:07:38 UTC 2008


On Mon, 07 Jul 2008 14:38:21 +0200, Igor Stasenko wrote:

> 2008/7/7 Klaus D. Witzel:
>> [sorry for cutting multiple Re's from the subject line]
>>
>> On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:
[...]
>>>>> 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.
>>
> of course, a difference lies only in a way how we sending message to
> object, wrapped by FarRef.

I think that the main difference we have here is induced by your "it is  
impossible by design to get direct reference to any object which not  
belongs to same island." which I take literally (without objection, to be  
clear). As a consequence, when running "in island #1" you cannot do

  proxy := anIsland2Object asFarRef.

instead you must do

  proxy := FarRef with: anIsland2Object.

and moreover [on a sideline, not so important] one cannot ask to which  
island *any* far (but as-yet-not-wrapped) object belongs.

Therefore I thought that sending something to a far (but  
as-yet-not-wrapped) object is like a DNU which the VM detects and  
automatically wraps into a FarMessageSend.

I think this is quite a difference to systems which would be based on  
manually wrapping (developer-driven-wrapping DDW), in which the impossibly  
to obtain a direct reference would be left to the developer (and/or  
her/his bugs).

>>> 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 :)
>>
> Nah!
> You don't need to use DNU pattern,

See above, not having sort of DNU can easily contradict your "it is  
impossible by design to get direct reference to any object which not  
belongs to same island". Somehow every *failure* to *not* get a direct  
reference must be detected and acted upon (note the negations).

---------------

If you like we can go into more detail in email (also addressing #new  
instances and their belonging to an owner).

> since you free to change a message
> sending semantics for FarRef.
> In this way, FarRef will act as transparent proxy, and ALL messages to
> it will lead to sending message to wrapped object which is located in
> different island.
>
> A FarRef could reserve a special selector for itself, like
> #performLocal: selector withArguments: args
> to send message to a FarRef object, not to wrapped object.
>




More information about the Squeak-dev mailing list