About FarRefs/Islands (Was:Re: [squeak-dev] Re: Prepare for Thousands of Cores --- oh my Chip - it's full of cores!)

2008/7/7 Klaus D. Witzel <[hidden email]>:
yes, in island1 you can't reach any object from island2. So the above
makes no sense, because you don't see anIsland2Object.
Or if you see it, it is already a FarRef, and therefore you don't need
putting #asFarRef.

But writing:

proxy := myLocalObject asFarRef.

does not contradicts with anything. You asking to wrap local object
with FarRef - no problem!

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

yes, its not really important, because the need in checking to which
island belongs FarRef really needed just in couple places when you
either sending message to foreign island or receiving message result
from it.

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

There is no VM, remember? No layer which magically controls such
cases, unless you provide such layer yourself ;)
They way how object(s) reacting on messages can be vary.
And you can't reach 'as-yet-not-wrapped' objects. All foreign objects
always seen by local islands as FarRefs.

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

Its not contradicts the rule - the DNU exception will happen in
another island and will be handled appropriately.

> ---------------
>
> If you like we can go into more detail in email (also addressing #new
> instances and their belonging to an owner).
>
This really a tough question :)

The reason, why i don't want to have island1 to play directly with
objects in island2 is because, if we do everything clean, it will be
possible to run GC on a per-island basis without preempting any
processes running in another islands, and without need in inventing a
concurrent GC, running in separate thread.

Classes (or at least its parts which responding for behavior of
objects) should employ some kind of sharing between islands.
Otherwise, everything will fall to same model, which currently Hydra
employs - island == separate image.

I'm not ready to answer this question. :)
I can only describe a situation, and problems i see. (I guess Andreas
have more to say, because he did that once)
Lets look on it from the very start:
Suppose we having island1, and creating new island2. Now we want to
populate it with objects.
Since island2 initially does not contains any objects, first
message(s) would be messages to island itself.
Lets suppose a blatant code sample:

farIsland2 := Island new.
farArray := farIsland2 do: [ Array new ].

So, here we created new island, and putting Array instance in it, and
result of the whole expression should be FarRef pointing to that
Array.
It is clear, that it will not go as we want to:

First, an 'Island new' should return a FarRef - a far reference to
newly created island.
So #perform: is FarMessageSend.
But since we passing block closure which belongs to current island, it
will be wrapped with FarRef.
So, then when its going to send #value to block (in implementation of
#do:), this leads to another FarMessageSend.
And finally, block will be performed in island1 , and new instance of
Array will be created on island1 instead of island2 :)


--
Best regards,
Igor Stasenko AKA sig.