[cap-talk] Memory Accounting without partitions

[Jonathan S. Shapiro]

On Mon, 2007-06-25 at 10:43 -0400, Sandro Magi wrote:

> As an aside, I assume efficient EQ tests are necessary for some
> important reason. I've followed a few discussions here where it was
> claimed that EQ is not necessary except for one or two patterns. So the
> question is: do those patterns need an *efficient* EQ? I believe
> efficient EQ is important for capability OS uses, but I'm not certain of
> the necessity in a language.

Speaking as a programmer, I would be reluctant to use a reference-based
language that did not implement an efficient EQ test. There are too many
real bits of code in my experience that have no efficient implementation
without one. EGAL might be sufficient for those -- I have not had time
to think about it.

> > This does not seem to solve the problem. Recall the original problem: we
> > wanted two parties to be able to hold references to an object. Either
> > party can drop their reference. We want the "appropriate" party to be
> > charged when this occurs. Severing/destroying the object doesn't help
> > us, because the non-creating party may still need to use it. 
> 
> You implicitly assume that releasing the real reference means the object
> will be collected; the other possibility is that the object remains live
> as long as there are outstanding caretakers (same behaviour as E I believe).
> 
> The question then becomes: who is charged for the storage if only
> caretakers reference it? The only viable answer seems the agent that
> released the handle, and thus owned it last. This ensures the agent has
> sufficient incentive to properly manage the storage, since if he doesn't
> explicitly transfer ownership before releasing handles, he will
> eventually strangle himself.

But the whole point of the caretaker is that it is an invisible
forwarder. In consequence, there is no operation that a caretaker *user*
can perform in order to cause the caretaker to be released. Given this,
I do not think that this accounting approach works.

> Assuming ownership hand-off is actually intended, this requires an
> explicit ownership transfer, effectively swapping the polarity of the
> caretaker and reference; I had noted could be provided as a primitive. I
> realize this approach involves additional memory management complexity,
> but let's establish whether it solves the problem first.

I believe that this approach makes the caretaker unnecessary. Once the
protocol includes provision for negotiation of accounting, I think the
whole thing can be done without a caretaker.

But back up a second and notice what is really going on here. The
problem we are really trying to solve is the absence of a "session"
construct (no "close" operation). The caretaker is actually a mechanism
for introducing sessions. This ought to lead us to wonder whether
sessionful communication wasn't what we really wanted in the first
place. If so, that leads in very different directions from capabilities.

There is a "dual" design issue as well: how does a server get notified
when the last cap to a given object is dropped?


shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC