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

Joshua Gargus schwa at fastmail.us
Mon Jul 7 17:32:59 UTC 2008


On Jul 7, 2008, at 7:07 AM, Klaus D. Witzel wrote:

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

Of course not... you can't have a direct-ref to anIsland2Object in the  
first place.

> instead you must do
>
> proxy := FarRef with: anIsland2Object.
>

Nope, can't do that either (for the same reason).

To create an island in the first place, you evaluate

	anIsland := Island new.

This doesn't give you a direct-ref to the island; it gives you a far- 
ref to it.

You can instantiate a new object on the island by sending #new: to the  
island.

	aMorph := anIsland new: Morph.

Of course, this gives you a far-ref to the newly created morph.  If  
you send messages to this object, the answered object is also wrapped  
(for most objects anyway; some types of objects are copied).

	subMorph := anIsland new: EllipseMorph.
	aMorph addMorph: subMorph.
	subMorph owner.              "a FarRef to aMorph"
	aMorph submorphs.         "an Array of FarRefs to Morphs"
	aMorph position.                "a Point (a copy of the on-island  
Point)"


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

Every process is associated with an island, so any unwrapped object is  
associated with the island of the currently running process.

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

In terms of Tweak and Croquet, Tweak FarRefs do work by using DNU.   
Croquet TFarRefs require an explicit #future message to be sent to a  
far-ref.  For example, the above would look something like (neglecting  
how to connect to a Croquet router):

	anIsland := TIsland new.
	aMorph := anIsland future new: Morph.
	subMorph := anIsland future new: EllipseMorph.
	aMorph future addMorph: subMorph.
	subMorph future owner.              "a FarRef to aMorph"
	aMorph future submorphs.         "an Array of FarRefs to Morphs"
	aMorph future position.                "a Point (a copy of the on- 
island Point)"

The original implementation had #future return a proxy object.  In the  
current implementation, #future is a keyword that is handled specially  
by the Compiler.  It's a bit more verbose, but on the other hand, all  
#future messages to a TFarRef result in network traffic, so being  
explicit makes it easier to keep track of what is going over the wire.

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

Yes, definitely.  If it is easy to cheat, then developers will cheat.

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

As described above, DNU is one way (but not the only way) to do this.

Cheers,
Josh


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