Michael van der Gulik
mikevdg at hetnet.nl
Sat May 10 14:23:04 UTC 2003
Anthony Hannan wrote:
>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
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.
>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.
More information about the Squeak-dev