At 07:58 PM 6/27/00 -0400, Jonathan S. Shapiro wrote:
>1. The runtime system must not allocate storage dynamically except in
>response to a specific program statement that requests an object allocation.
>Ever. No exceptions. None. Really, none. No, not for that reason either.
>This rules out every current OO or high-level language I know about.
>
>
>Why: Unless the total storage allocation that occurs as a side effect of
>runtime requirements is statically boundable it is not possible to avoid GC
>in the kernel. If things get bad enough you get prone to deadlock. The
>hash-memoization mechanism used by Objective C (which, by the way, first
>appeared in MacLisp and was later reimplemented by yours truly for Franz
>Lisp) requires such a dynamic allocation.
KeyKOS had two kinds of kernel storage allocation. Most of the allocation was like that used in a cache. I.e., if you can't allocate a block, pick some already allocated block, deallocate it, and use the space. (This approach might work for the hash-memoization example.)
The other approach was used by the I/O system. If a block could not be allocated, the responsible domain waited on a "noFreeBlocks" queue until completion of some current I/O operation make space available.
Neither of these approaches to running out of storage are easy to implement if the compiler is allocating behind your back.
>2. Runtime overhead is the enemy. Abstraction at the level of syntax is a
>useful thing to have. At the level of code generation it is completely
>unacceptable to pay anything for it. Macrokernels may be a different story,
>but microkernels really want to be implemented in a high-level assembler.
The first version of KeyKOS was implemented in a high level assembler. (IBM Assembler H with structured programming macros.)