On Tue, Dec 12, 2006 at 12:05:39PM -0500, Eric Northup wrote: > Sam Mason wrote: > > On Tue, Dec 05, 2006 at 04:30:10PM -0500, Swaroop Sridhar wrote: > > [...] > > Would naming space banks preclude having an arbitrary number of them? > > My naive interpretation of naming suggests this, but I don't know what > > you're thinking about them. > > On an OS rather than programming language granularity, the number of > Space Banks a KeyKOS/CapROS process had to chose from while processing a > message is typically either one (which the process had from the > beginning) or two (for a multi-client server process, one which to > server had from the beginning and another provided by the client being > served). When more storage sources are available to chose from, it > becomes much harder to identify a single, correct party to charge for > an allocation.
Interesting, it's nice to have things like this described. It's the sort of thing that's difficult to find. I can see how it would be difficult to know who to charge when you've got more than two sources. I'm not sure if it helps but I see a very shallow hierarchy here. The "outer" space bank of the server process (which will exist for the duration of the server processes life) and the "inner" space bank of the client which will appear after the server's space bank and will be released before the servers space bank. Storing pointers within a space bank is obviously easy. Storing pointers in an inner bank from an object in an outer bank seems OK. Any other composition seems error prone. This seems to me pretty much what "regions" were about in Cyclone though. Garbage collection of the outer bank still seems difficult though. > That said, I see no reason why naming space banks would preclude having > an arbitrary number of them. For example, represent space banks with an > opaque reference type (as they are in KeyKOS-derived designs) passed as > an extra argument to dup. This is sort of what I was thinking. Not sure how useful it would be in practise though. Or how you stop references escaping. > A more serious problem with to space bank analogy is that, in KeyKOS et > al, the party who provided a space bank is allowed to destroy the bank, > reclaiming all its storage. Recovering from that event is a non-issue > if an entire process was allocated from the destroyed bank, but > trickier in a multi-client server when a single client's bank > disappears. I don't see how to model either case in a memory safe > language like BitC. Not sure if that is ever going to be easy! Sam _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
