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