[cap-talk] Capability accounting

[Karp, Alan H]

Jed wrote:
> 
> 2.  Regarding "There is no garbage collection in Keykos ...".  That's
> the same philosophy we took, really by necessity, in NLTSS.
> The attitude was that, while objects could indeed become "lost"
> (possibly no or at least no easily found instances of capabilities
> to them), they were still accounted for.  Whoever was responsible
> for the account would have an incentive to clean up and destroy
> the unused but still allocated resources.  We had a mechanism
> whereby the owner of an account could produce new capabilities
> for objects being charged to the account.  Such capabilities could
> be produced (reproduced one might say) and then destroyed if
> that was their appropriate fate.
> 
Client Utility and e-speak were able to do garbage collection.  That's
because all requests were made by a local client with a c-list visible
to the system.  Hence, we were able to identify unreachable resources
and delete them.    Once the last transitive reference to a resource was
removed from the c-lists, the resource was forever unreachable and could
safely be garbage collected.  It was "transitive" because resources were
discoverable, but we could determine which resources could not be
discovered.

We didn't solve the problem of distributed garbage collection.  A remote
client could have forgotten a reference to a resource, but we couldn't
garbage collect that resource as long as the local proxy held a
reference.  That's where we used your approach.  The quota system gave
the remote client an incentive to clean up its proxy's references.  We
couldn't use your approach of letting the owner create a new capability
for the resource because we had no concept of owner.

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories 
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 423 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20060622/1d92e95c/attachment.vcf