[cap-talk] Memory Accounting without partitions(was: Language-based OS domain separation.)

[Jed Donnelley]

At 09:58 AM 6/16/2007, Jonathan S. Shapiro wrote:
>On Sat, 2007-06-16 at 08:44 -0700, Jed Donnelley wrote:
> > At 08:14 AM 6/16/2007, Jonathan S. Shapiro wrote:
> > >Okay. All of this makes sense. It also follows my rule of thumb that "he
> > >who pays must be able to deallocate".
> >
> > We had a similar working rule in our NLTSS system.  It's difficult
> > for me to imagine a workable system without this criteria being met.
>
>I would be curious how often anybody actually "pulled the trigger" on
>reclaiming such storage. While I definitely think this rule is
>necessary, current programming languages really aren't prepared to
>recover from memory maps simply disappearing out from under them, and
>programmers are generally not prepared to build defensively w.r.t. this
>type of issue.
>
>How did developers deal with such matters in NLTSS?

Perhaps if I explain the context of NLTSS it will be "elementary
my dear Watson".  Our issue was objects of any sort that were
charged for (e.g. files, directories, processes, etc.).  The
danger that such objects could become "lost" (e.g. no longer
available to anybody responsible for the account paying
for them).  They could become traditional "lost objects"
(no capabilities anywhere - I know, many systems deal with
such cases with reference counts and garbage collection,
we didn't for reasons I will explain) or it might
happen that they still had pointers somewhere that those
paying for them couldn't access (e.g. given to some other
"user" with a local pointer deleted).  For us it became
clear that the old approach of using reference counts
was inadequate.  It didn't matter if there were still
pointers, if you were paying for something and didn't
want it any more, you wanted to delete it.

Our expedient was to allow those paying for objects
to recover capabilities to them.  This is one reason
we had names associated with the objects themselves
(distinct from any name they might have in a directory),
just to be able to better identify them.  At a reporting
time accounts could return capabilities to all the
objects they were paying for.  Of course it might be
a bit difficult to decide what all those objects were
being used for.  People could search their directory
structures and match found objects with those they
were paying for.  Any others might (to their possible
dismay) be considered "lost" and destroyed.

One value that I could see from "responsible delegation"
as with Horton is that accesses to objects could be
tracked by responsible identity.  In that case if an
object appeared "lost" one could look at the
responsible identity for the last accesses.  Possibly
a place to look for continued value for an object.
"Hey Bob, do you know what this file 'Foo' is?
What were you doing with it back in March of 2002?"

Could be a rather painful process, but it seems to
me the needed pieces were there.  In practice
people using NLTSS never really needed to resort
to such measures as we were, sadly, emulating an
ordinary hierarchical file system where it was
rather difficult to "lose" objects.

--Jed  http://www.webstart.com/jed-signature.html