[Cross-space references] NewtonOS and Sessions

Rob Withers rwithers12 at mediaone.net
Wed Aug 29 03:24:17 UTC 2001


Hi Jecel,  I'm sorry about the delayed response, but I wanted to get the
code prepped and posted, this past weekend.

comments intespersed...  (I don't have Word loaded so no spell-checker..I am
sorry for my english!)

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


[snip]
> My idea is to cache read-only state locally (we are talking about
> distributed systems now, right?) but you inter-node messages to access

I did shift to distributed systems as the highest latency case.  Like you
mention shortcutting the pointer between segments, I have imagined that a
lower latency situation (inter-thread) would have a different copy policy.

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

Ahhhh.  It is a distributed transactional issue, is it not?   We want to
ensure that state is modified and that all other clients with a snapshop get
invalidated as a result.   From what little I have heard about Tensegrity,
it does some interesting things to solve this problem.  I am probably off
the mark...I believe that to deal with multiple distributed events, which
mutate state transactionally, the concept of an event horizon was used, and
so these events were viewed as relativistic.  there is evidently some math
that then comes into play to figure out who was first, the earlier sender of
an event or the event that arrived first.  I wish I knew more about this:
does anyone have information (anyone that has read this far....:-)?

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

Now that's interesting.  Don't some functional programs keep shared state
until it is mutated, then a diff is made for that mutation/reference?

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

drool! wipe chin.  This is it.  This is the kind of dynamic task mobility
system that I would *luv* to see Squeak be capable of.  A distributed Linda
may be the way.

[SRP]
> 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.

But since we can control the rules that a particular stream is configured
with, then we don't need all of the dialect indepenent Rules that convert to
an intermediate form.  In that minimal case, where no mapping to an
intermediate form occurs, just marshalling to a flattened state, then isn't
the algorithm fast?  Granted image segments are supposed to be faster, but
that is to disk, isn't it?


[Distributed Objects and GC]
> > > 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.

This stumped me.  The only thing I can think of is that these are two
different segments, therefore the local handles may be the same for
different objects in each seqment, but when we externalize the handles to a
global handle, they would include the handle to the segment which is
different.  If we have the same object externalized in 2 segments, with
different local handles, then when we externalize the handles, they will be
different, but should they be identical? or equal?  It's a frame of
reference issue.

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

Aren't we are speaking of circular references across machines with
forwarding pointers, for purposes of GC, and not algorithms for flattening a
graph which may have internal circularities?  If I may attempt to provide an
example.  If object a, space A has a pointer to object b, space B  and
object b, Space B has a pointer to object a, Space A, then we have a
circularity that may avoid collection without a globalGC.  We microGC space
A and, hello, we have an in-pointer to object a from (b, B).  The same
situation exists for space B.  So how do we get rid of this?  (I have no
idea - I thought I did when reading Stephen Pair's discussion)

cheers,
- Rob





More information about the Squeak-dev mailing list