On Thursday 23 August 2001 19:25, Robert Withers wrote:
> I think this is where the GC would operate as well.  I almost had one
> working, but I didn't finish the GC, because of the additional
> coordination that was required.  I need to resuscitate this code too.
>  Are we both thinking that some heuristic would cache state locally,
> like the Gemstone Proxy model? 

My idea is to cache read-only state locally (we are talking about 
distributed systems now, right?) but you inter-node messages to access 
remote mutable state. Previous designs with modified/shared/invalid 
coherency protocols were too complex and performed not better than this 
course grain (per segment) solution.

Note that the bulk of state in a "normal" Squeak session is read-only. 
How many times are you editing the Forms in a font?

> More advanced optimizations as well -
> one that I like is usage-based relocation.  To increase access
> locality, we may want to make a remote object, local, and then it
> would be remote in the former local space.

See the "computational field model" in Mario Tokoro's papers (5, 6 and 
7 in http://www.mt.cs.keio.ac.jp/techpaper.html). This is also good for 
global collection of circular garbage, as Allen mentioned in a related 
thread.

> > I found SRP very interesting though it seems to be designed for
> > "off line" transfer of binary objects between systems and not for
> > performance critical operation. Its compressed encoding was the
> > inspiration for my own variations on this idea.
>
> Not true, in my experience.  All of the examples with the base are to
> and from disk, but it is an ObjectStream and as such, it can be
> opened on an underlying stream  (BufferedSocketStream of some kind). 
> I actually chunked each flattened graph, and read in chunks at the
> other side.  Squeak sockets had the occasion to return nil and other
> peculiarities; Socket and the streams aren't (or weren't) positional.
>  The real solution, IMHO, is to use Flow's NetStream as the
> underlying stream.

By "between systems" I meant one system running Squeak and another 
VisualWorks. A lot of SRP's complexity isn't needed if you have just 
one kind of system on both ends.

> > Can you convert internal references into smart external ones
> > automatically?
>
> This was done by the SubstitutionRule, that I wrote.  For 'matching'
> (hah!) objects, it would register the object in a local table with a
> new local handle.  At the remote site, I would register the handle in
> a table. Out-pointers and In-pointers.  At the remote site, I would
> wrap the handle in a Proxy.  I need to look at GemBuilder for Squeak.

As long as this is just a run time thing, there should be no problems.

I had the following complication: imagine a read-only segment. It has a 
number of externally known "root" in its in-table. By executing some 
code in a node, I might expose another object from the segment so it 
must now have an entry in the in-table. The contents of the segment 
haven't changed, so it really is read-only. But its in-table isn't. In 
a very distant land, another node is also executing code from this 
segment. It too ends up exposing what was a previously internal object 
and so must extend the in-table. Since the two machines didn't 
coordinate their efforts, two "replicas" of the same segment now use 
the same entry of their in-tables for different objects.

> > > Gemstone controls the fault depth for a graph of objects [...]
> > This is also a great way to avoid getting stuck in circular
> > references
>
> I don't follow you here.  How does it avoid this?  I think there is
> extra work to do, with the LoadRecepticles of SRP, to avoid this. 
> For one Marshalling it does and one pass with forwarding pointers,
> but there is more identity issues for objects between marshallings.

If you use forwarding pointers to avoid copying objects more than once, 
then circular references are no problem. If you don't but are doing a 
limited depth copy, then at least circular references don't get you 
stuck in an infinite loop.

> I originally got this idea from David Caster, who implemented it
> once, in Squeak.  He could call into the image from external land, in
> a synchronized way.  This is the inspiration for the queues and
> futures work that I did, and he helped me considerably.

I haven't checked to see how Nebraska handles these problems. That 
might be a good idea.
-- Jecel