[cap-talk] Object Allocation

[Jonathan S. Shapiro]

On Fri, 2007-07-06 at 16:05 +0200, Tom Bachmann wrote:
> So what "basic resources" are there that would need "static
> constructors"? Processes, address spaces, memory and capability pages
> come to my mind, but the exact list is not important, I think.

Umm. Hopefully somebody will chime in for the language case, because I
am interested if their view may differ.

In the OS case, the exact list is important, particularly in the area of
address spaces, because it tends to be VERY difficult to emulate these
correctly. Consider, for example, that 68040 or i386 can do atomic
misaligned fetch across a page boundary. If you simulate a page, that's
essentially impossible to simulate in any cost-effective way. Similarly,
you can emulate a process, but you cannot stick the emulation object on
a kernel ready queue.

At considerable cost, these issues can be resolved, but the cost is
generally not worth it.

So the list is important because, in practice, the abstractions for
these objects tend to be imperfectly maintained. I do not consider this
fatal. Norm considers it more important. Jed considers it imperative.

In language-based systems, it seems to me that real storage allocation
is deeply primitive and not emulatable -- at least in part because a
tight binding must be maintained between the memory allocate step and
the construction step in order to ensure type safety.


Finally, note that "real" resources are exhaustible, and do not tend to
be fungible (you can't create a process from a page by trading memory)
because of this, the consequences of exhaustion are very concrete.
Higher-level "composed" resources tend to have more fungible sources of
storage, and the likelihood (therefore consequences) of allocation
failure become progressively "softer" as you move up the abstraction
chain.

shap