Hi Jecel,  brief comments follow

----- Original Message -----
From: "Jecel Assumpcao Jr" <jecel at merlintec.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, August 22, 2001 4:57 PM
Subject: Re: [Cross-space references] NewtonOS and Sessions


[snip interesting architecture]

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

It's a pointer swizzle.  I like the idea of controlling the reference and
changing it's state (perhaps by an optimizing manager and not the client of
the reference), like faulting the methods or state locally or defaulting
then remotely.

>          myGraph := rmObj graph.

SRP, that I just mentioned, does this with rules that control whether an
object is pass-by-value or -ass-by-reference and whether the MetaState
should be serialized.  Always make external references smart, seems like the
simplest design.

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

Gemstone controls the fault depth for a graph of objects.  It says only
fault in objects within 2 edges of me and stub the rest.   That would lead
to localization of objects accessed often and dynamically determine the
clusters that get faulted.

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

If the references are handles to a table, and we can restrict access to that
table, then we can really hide external objects from prying hands.  I also
liked the idea in Newton  of using Ports for communication.

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

Ahh..sounds like a job for a GCed transactional persistent heap!  ;-)

- Rob

> -- Jecel
>
>