[cap-talk] Object Allocation

[Chris Hibbert]

> 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.

> 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.

I want to say a quick word about the difference between fundamental 
system-specific interfaces (which have the interdependencies you 
mention) and a more general-purpose interface usable for allocating 
application objects.

I think you get that distinction by defining a general-purpose interface 
that can be used at the application level in a generic way.  (Or maybe 
by a useful library at the application level that hides some of the 
details from the programmer.)  But the system-dependent version has to 
be built and used by the system programmer to adapt to each specific 
system and language.  Whoever's implementing a new VM or runtime needs 
to pay attention to the petty details about page alignment, behavior on 
faulting, timing of clearing the bits, etc.  So there is an 
implementation that pays attention to those details and makes some of 
them accessible to the next layer up, but at some point, that gets 
wrapped in a version that sweeps those ugly details under the carpet and 
pretends that it's just pages that can hold bits or objects.

The hard part for the initial designer/architect to understand is that 
boundary between system-specific and generic doesn't have to be the same 
on every system.  It's really important that the general-purpose 
interface be portable, but the implementation and interface for the 
low-level stuff can vary between instances.

Chris
-- 
Currently reading: Sunny Auyang, How is Quantum Field Theory
    Possible?; Thomas Sowell, Black Rednecks and White
    Liberals; Greg Mortenson and David Relin, Three Cups of
    Tea; Tracy Kidder, House; Sherri S. Tepper, The Fresco

Chris Hibbert
hibbert at mydruthers.com
http://mydruthers.com