Squid plan

Anthony Hannan ajh18 at cornell.edu
Fri May 16 17:35:15 UTC 2003


Hi Jecel,

Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
> Multiple "VMs" are needed if you don't have enough security or if you can't take 
> advantage of multiple processors. Otherwise I don't see the point.

Agreed.  I hope Squid can handle both security and multiple processors
internally so we won't need multiple instances.

> So several [Smalltalk] stacks can live in a single segment?

Yes.

> We are talking about MMU segments or Squid segments here? Or is
> there no difference?

Squid segments.  Maybe MMU segments can be used to implement them if it
would help performance or design (I don't know), but they may be too
machine dependent.

> How about Eliot Miranda's bytecode-to-bytecode optimization project?

Exactly, I'm hoping to use this.

> > What about just flushing the mmap in my scheme instead?
> Things are being flushed all the time, so a crash will almost certainly 
> results in a "partial flush".

What if I use msync?  It forces a write to disk the the address ranges
you specify.
But I am open to trying your scheme as well (using a write log).  We
should keep the implementation decision hidden in the Segment module.

> In a previous design I had "segment owners", as suggested by Michael. My 
> policy was:
> 
>  - if the owner of a read-only (for others) segment was not currently 
> logged in the local network, then the segment is replicated
> 
>  - if the owner is logged in and tries to access an object, the segment 
> is moved to his node(s) [(replicas are removed)]
> 
>  - if the owner is logged in and another user tries to access and 
> object, the message is forwarded to the current location of the segment

I like it.  But I'm leaning towards replicating an object and its free
children, not whole segments.  I know an object and its free children
could actually define a segment, but I am defining a segment more
broadly as any cut/region/subgraph of the global object graph.  Each
segment resides on a specific machine.  Instead of segments being
magically distributed/replicated, objects are.  This allows us to
implement the magic in the object domain instead of at a lower-level
(another example of moving thing out of the VM and into the image).  If
we still want to group objects, we can add owner fields to the objects
like you are suggesting.

> The hard part is knowing when an object can be removed from its
segment roots array [(Distributed garbage collection)].

Instead of a single roots array, there is one per outside segment that
references it.  So each segment knows every other segment that has
references to its objects.  When an object is no longer referenced
locally but is still referenced from the outside it is moved to one of
these segments and the others are updated to point to it.  If there are
no more outside references then it is simply garbage collected.  Hence
we have distributed garbage collection.

> I keep all objects around forever.

With no garbage collection, how do you free memory?

> > The runtime system is written in Smalltalk and Smalltalk assembly,
> > instead of Slang and C.  Calls it makes to native libraries are done
> > through this C interface.
> Ok, but my question was how are the native libraries linked to this? 
> Dynamically (DLLs and friends)?

Yes.  The squid C interface will load the referenced library (dll) if
not already loaded then call the desired C function.  The loadDll
function itself will have to be statically linked with the boot module
so we can use it.

> > > This has a lot in common with some of the stuff I am doing, so we
> > > might be able to work together. 
> > That would be great.  I think we should continue this discussion so
> > we can agree on the overall design.  Do you have any links I should
> > check out.
>   http://www.merlintec.com:8080/software/8

I checked it out.  Very interesting.  But it seems a little complex to me. 
Maybe your combining too many concepts (viewpoints, replication,
versions) into one (segments).  My approach is to do it in layers. 
Segments first, then replication, then versions, then modules, etc.. 
All are independent concepts.  (I have not talked about replication and
versions yet but I will).

Cheers,
Anthony



More information about the Squeak-dev mailing list