Anthony Hannan wrote:

>Segments
>
>Each squid file contains a segment of objects.  Objects can point to
>objects in other segments, using cross pointers.  Following a cross
>pointer causes the target segment to be loaded, if not already.  Files
>are kept in sync with with their loaded segments (mmap) maintaining
>persistence without explicit saving.  Cross pointers may cross machine
>boundaries.
>
I've been thinking about this, although not in enough depth yet.

Would it be easier to have explicit object ownership? Every object has 
an owner. That way, a "segment" is a group of objects with a common 
owner. Alternatively, a "segment" may not have out-going pointers, and 
can only use an owning object as a sort of proxy should they need access 
to the outside world. This is an idea; I haven't actually thought far 
enough to think if it would actually work. I think this is most useful 
with composite objects, e.g. collections.

This would affect a lot of things. For starters, we knew exactly which 
objects to move to disk / migrate to another computer / etc. It provides 
a nice level of granularity for automatically replicating objects. The 
garbage collector could keep ownership in mind - child objects can't 
have external pointers so the GC can skip over whole segments, and also 
do localized GC's within a particular area.

This has bigger implications for managing a long-running persistant 
system. Sometimes a user simply needs to clear out a lot of old junk; 
with explicit object ownership, the user can see how much space a 
certain object and it's children are actually using. This may also allow 
for security - an owning object need not / cannot (perhaps?) give away 
references ("capabilities") of it's children.

In terms of remote objects; I much prefer to do that on top of the VM 
rather than as a feature of the language. The most important trick is 
that an object can pretend to be another object. This can be done in 
Smalltalk (?) using doesNotUnderstand:, but that sounds hacky. Faking my 
own identity means that I can act as a stub for a remote / replicated 
object, or as a placeholder for an object that's not in memory yet, or 
several other uses. I don't think that a VM should be responsible for 
doing remote objects; it's a bad idea to tie the implementation to one 
manner of remote invocation over one protocol.

>Remote Pointers
>
>Cross pointers across machines must be established and maintain and
>robust against failure.  When accessing a remote field or invoking a
>remote method execution can move to the remote machine or the
>object can move or be replicated to the local machine.
>  
>
Will this be implemented at part of the VM or in Squid code ontop of the 
VM? (okay, there's no VM...). I'm hoping that you're going to leave a 
mechanism open for one object to fake it's identity, so that it can act 
as a stub for a remote object. There are a lot of different replication 
algorithms with different performance charactoristics. I'm hoping that 
you're not going to hardwire anything in.

Michael.