On Tuesday 21 August 2001 22:31, Robert Withers wrote:
> > ["boot session" and "user session"]
>
> This is exactly what I would like to see within one Squeak image.
> Communication should be normal sends, and the context of the
> reference should transform that send appropriately.

In my initial design, each session had a separate address space and it 
made no difference when sending a message to in object in another 
session whether that session was in another machine or not.

Later I decided that the boot session should be able to export some 
memory regions as read-only to the user sessions. All sessions have the 
same memory map, but with different permissions (like the Newton). So 
user sessions can execute locally methods that don't change the system 
objects and simple memory pointers can be used as references betweeen 
sessions in the local machine. Among the exported regions are things 
such as the message lookup cache and the JITter compiled code cache.

> > I started working on my design in 1984. It isn't simple to get it
> > simple. Lately I have made progress by throwing things out,
> > including cross space references (if you don't count proxies).
>
> So you used to have a cross-space reference that wasn't a proxy
> pattern?  Or rather it was implemented differently than the standard
> "subclass from ProtoObject" style proxy?  If so, how did you work it?

I have considered many alternatives. My very first design was "cached 
smart references" where each remote pointer had a block associated with 
it like [ (Smalltalk at: #IO) currentDisk ]. After loading the 
different segments into memory, the first time you tried to follow this 
reference the block would be executed in the local name space and the 
resulting memory pointer would be saved to make accessing the "remote" 
object faster from then on. The Texas Persistent Object Store (among 
others) has something very similar. You need a lot of manual set up for 
this to work - things get very nasty when an innocent expression embeds 
a non smart reference to a remote object in a local object:

         myGraph := rmObj graph.

where rmObj is a carefully hand crafted "root" in the other segment but 
its graph is not.

Another design had pointers to local objects be 32 bit integers 
indicating the object's byte offset in the segment file. Pointer to 
remote objects were negative integers and the segment was mapped into 
virtual memory with the pages right below it set to trap. This trap was 
used to check an "out table" to find the remote reference and patch the 
offending pointer (after loading and mapping the other segment, if 
needed).

After that I made all pointers be local but with some objects as 
proxies for remote ones. This just spread the "out table" throughout 
the segment instead of having it as meta data. In my latest design it 
isn't so much that I eliminated the proxies, but really that I have 
made all objects proxies ("patches" since they aren't pure proxies).

>  I have a proxy that works, and with the Delegation model, from
> Stephen, we can preserve identity; however, I want it to be
> completely transparent, if possible.  It would require VM support, I
> believe.  I am clearly violating the 80/20 rule, but I feel that it
> would open many, many doors.  It is a pluggable proxy, with the
> ability to transform the message send. It should be completely
> weightless, aside from the oop header and 2 slots, target and
> messageManager.  Perhaps we have a registry of managers, that we
> lookup using a referenceHandle, to cut an oop from the stack.  If we
> could use a bit in the Oop header, we may be able keep it to 2 words.
>  Thus I am out to learn the vm, and stop talkin' about it so much. 
> :)

All my designs suppose heavy vm support. Squeak won't be able to avoid 
this if the SqueakNOS effort gets far enough. You can rely on the 
virtual memory (the other vm...) in Linux, Mac or Windows but what do 
you do on the bare hardware? Limit yourself to images smaller than the 
RAM? I have already counted all you people answering "yes" to this one, 
so don't bother emailing ;-)

-- Jecel