Tweak Islands (was: Re: BabyUML overview posted)

Bert Freudenberg bert at impara.de
Sat Sep 24 17:01:02 UTC 2005


Am 24.09.2005 um 14:38 schrieb Trygve Reenskaug:

> Bert,
> My reverse engineering study is, of course, not a conclusive  
> analysis of Islands as such. It is merely a snapshot of a  
> particular instance of an island with an operation or two + an  
> evaluation of its suitability as a foundation for my work with  
> BabyComponents.
>
> I see that my statement about 'free floating objects' has been  
> interpreted in a way that makes it false and I apologise for not  
> being sufficiently clear.
>
> My point is that island membership depends on the island of the  
> current process; it depends neither on any feature of the object  
> itself nor on a feature of the Island object. In fact, membership  
> is a dynamic property:
>    Object>>island
>       "Answer the receiver's island"
>       ^Processor activeIsland
> Processor is a global variable, an instance of ProcessorScheduler.
>    ProcessorScheduler>>activeIsland
>       "Answer the currently active Island."
>       ^activeProcess island ifNil:[Island default]
> and
>    Process>>island
>       "Answer the receiver's island"
>       ^island
> Deep down, an object is on the island that is currently stored in  
> activeProcess. It is not a static feature of the object i

Not quite. You are right in so far, that if the sender of the #island  
message lives in the same island as the receiver, it will get the  
active island. This is correct, because by definition the control  
flow tracks the current island.

However, if the sender of the #island message lives on a different  
island, it will not have a direct reference to the receiver, but a  
FarRef. And FarRef maintains a pointer to the object's island, it  
will answer that island, and not the process' active island.

> A second point is that I haven't found any way for finding all  
> objects on an island.

Finding all objects from an island is very important, islands are the  
basic mechanism of project storage in Tweak.

We use image segments for this - all FarRefs are marked as roots,  
then a marking algorithm traces all references (similar to how GC  
works). See IslandWriter>>snapshot:

> I find the first comment misleading.

True, even though it is correct. We should mention that this method  
is polymorphic to FarRef>>island.

> The second is correct; the method returns the currently active  
> Island. The third is also correct because the receiver now is the  
> activeProcess.
>
> In my report, I chose what I thought was a simple way to illustrate  
> this dynamic nature of island membership. Here are three other ways:
>
> (1)
> Start from the inspector shown, inspect innerObject. You get a  
> FarRef. Select and inspect myValue. You get an inspector on the  
> inner object. In this third inspector type and print 'self island'  
> in the bottom pane. The result is that the inner object is on  the  
> Squeak island.

This is because the inspector is (and currently must be) able to  
break the island boundaries.

> (2)
> Add this method:
>     IslandServerInner>>initialize
>         super initialize.
>         Smalltalk at: #INNER put: self.
> Run
>    'IslandClient new test'
> and then evaluate
>    '(Smalltalk at:#INNER) island. '
> The answer is again the Squeak island.

This is because accessing global variables (like Smalltalk, Classes,  
etc) is not yet protected. The byte code interpreter directly  
extracts the value member of the association stored in the method's  
literal frame, rather than sending the #value message. If this was  
the case, INNER would be a FarRef.

>  (3)
> Execute
>    IslandServerInner allInstances collect: [:inner | inner island]
> and get:
>    #(an Island(Squeak) an Island(Squeak) an Island(Squeak) an Island 
> (Squeak))

Again, this uses a global along with a mechanism (object enumeration)  
not yet supported in the Island code.

> I have clearly the results of several test runs sitting in my  
> image. The four inner objects have all been created on an  
> IslandServer. Nevertheless, all here appear to reside on the Squeak  
> island. (I expect they will still be on an IslandsServer if  
> approached correctly.)

Indeed.

> It seems to me that the Islands philosophy is to maintain an  
> island's member objects by strict border control. The objects are  
> not floating free -- as long as all accesses pass through the  
> border control. I have, in a sense, been observing the member  
> objects from above through regular Squeak Inspectors and the BabyRE  
> reverse engineering interface. I circumvent the border control, and  
> the objects appear to be floating freely. Two perspectives, two  
> results.
>
>  I do not criticise the Islands vision or implementation. I have  
> found nothing wrong with it apart from the few comments that  
> confused me. I definitely see it as a valuable contribution. I  
> initially believed it to be closer to my vision of a BabyComponent  
> than it turned out to be, but that's my problem and does not  
> reflect on the Islands package as such.
>
> Keep up the good work!

We're trying ;-) Same to you!

- Bert -

> --Trygve
>
>
> At 18:07 23.09.2005, you wrote:
>> Am 23.09.2005 um 14:53 schrieb Trygve Reenskaug:
>>
>>> My reverse engineering of Islands may be of interest to others. I
>>> found the objects, their links, and their interaction pattern for a
>>> few interesting operations. The report is at
>>>   http://heim.ifi.uio.no/~trygver/2005/babyuml/tweakComponents.pdf
>>
>> Note, however, that this is not a conclusive analysis of Tweak
>> Islands. In particular, this statement is false  (as I explained in a
>> private message before):
>>
>>     "The objects themselves are floating freely and their island
>> property depends on the island of the
>> observer. The two last print it statements in figure 3 on page2  show
>> that the same object appear to reside
>> on two different islands simultaneously."
>>
>> This is wrong. Objects live on one and only one island (unless there
>> are bugs etc.).
>>
>> By using the #instVarAt: method you are actively circumventing the
>> Island encapsulation. This method was implemented in FarRef in
>> particular to aid debugging.
>>
>> In your test, innerObject is a FarRef to an IslandServerInner:
>>
>>     innerObject "Far serverIsland:[an IslandServerInner]"
>>     innerObject island "Far serverIsland:[an Island(serverIsland)]"
>>     innerObject asString  'an IslandServerInner'
>>
>> By calling
>>
>>     innerObject instVarAt: 2 "an IslandServerInner"
>>     (innerObject instVarAt: 2) island "an Island(Squeak)"
>>
>> you directly extract the value of the FarRef and thereby "tunnel" the
>> far object onto the current Island. When asking it for its #island
>> later, it of course answers the calling island.
>>
>> Without the debugging aids it would be impossible to directly access
>> objects on another island. Which would make debugging itself next to
>> impossible.
>>
>> - Bert -
>>
>





More information about the Squeak-dev mailing list