GUI systems

[Bill Frantz]

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