Garbage Collection, Tail Recursion and First-Class Continuations in Stack-Oriented Languages

1. Field of Invention

The present invention relates to the programming of a data processing system. More specifically, the invention relates to the implementation of advanced computer language features such as tail-recursion optimization, first-class continuations and garbage collection when implementing applications in a stack-oriented computer language.

2. Field of the Prior Art

Stack-oriented computer languages--e.g., Algol, PL/I, Pascal, Ada, C, C++, to name just a few--are utilized to program a large fraction of the computer applications software in use today, and the architectures of a large fraction of computers are optimized for these types of languages. The techniques for efficiently implementing these languages are well-known in the art of computer science, and are covered in a number of textbooks--e.g., [Aho86]. (References in square brackets appearing in the specification are described in Appendix A attached hereto.)

However, a number of advanced computer languages--e.g., Scheme [Scheme90], Smalltalk [Goldberg83], and ML [Milner90], to name just a few--incorporate advanced features that are not easily implemented on computer architectures optimized for stack-oriented languages. Some of these advanced features include tail recursion, first-class continuations, and garbage collection.

Tail recursion is often considered an optimization, which is a program transformation that improves the efficiency of the program in execution time or storage space. Tail recursion is a process of replacing a certain type of recursive computation by an iterative computation which more efficiently produces the same effect and/or result.

According to [Aho86, pp. 52-53], "Certain recursive calls can be replaced by iterations. When the last statement executed in a procedure body is a recursive call of the same procedure, the call is said to be tail recursive. . . . We can speed up a program by replacing tail recursion by iteration. For a procedure without parameters, a tail-recursive call can be simply replaced by a jump to the beginning of the procedure."

According to [Abelson85, p. 33] "Tail recursion has long been known as a compiler optimization trick. A coherent semantic basis for tail recursion was provided by Carl Hewitt . . . Inspired by this, Gerald Jay Sussman and Guy Lewis Steele Jr. [Sussman75] constructed a tail-recursive interpreter for Scheme. Steele later showed how tail recursion is a consequence of the natural way to compile procedure calls."

An advanced language that guarantees tail recursion--e.g., IEEE standard Scheme [Scheme90]--does not require special iterative or looping constructs in order to execute loops and iteration efficiently. Thus, the `do`, `for`, `while`, and `until` constructs found in languages like Fortran, Algol, PL/I, Pascal, C, C++, to name just a few, can be replaced by recursions which can be compiled as efficiently as the iterative looping constructs. This efficiency means that the complexity of compilers and programming languages which deal specially with looping constructs can be reduced by utilizing an efficient form of recursion in its place. Furthermore, according to [Kernighan88], ". . . recursive code is more compact, and often much easier to write and understand than the non-recursive equivalent."

Stack-oriented languages do not guarantee tail-recursive implementation of subprogram calls. Some particular compilers may provide for a tail recursion optimization in some particular cases, but a portable program written in a stack-oriented language cannot rely upon tail recursion on a wide variety of implementations of the language.

Another advanced computer language feature is that of first-class continuations. Continuations can be used to implement non-local transfers of control. A relatively simple kind of non-local transfer of control is that of the ANSI C language setjmp/longjmp pair [Kernighan88] [Harbison91] [Plauger92]. A C program may execute a setjmp function and then call a number of other nested functions. Within this nesting, a longjmp function can be executed which transfers immediately back to the context saved by the setjmp function. Any functions in the nest which have been called, but have not yet returned, will never return, and will simply be abandoned. A more sophisticated use of continuations is to implement multiple processes by means of interrupts and time-sharing [Wand80]. A still more sophisticated use of first-class continuations is Prolog-like back-tracking [Haynes87].

Stack-oriented languages implement only the simplest kind of continuations, if they implement continuations at all. ANSI C [Kernighan88] [Harbinson91] [Plauger92] is typical in that it defines the meaning of setjmp/longjmp only in the cases where the longjmp is dynamically nested within the enclosing setjmp. Furthermore, C makes no provision whatsoever for saving the result of a setjmp as a first-class continuation data object which can be passed as an argument to a function, returned as the result of a function, or stored into a programmer-defined data structure.

Another advanced computer language feature is automatic storage reclamation or garbage collection. Computer languages, including stack-oriented computer languages such as PL/I, Pascal, Ada, C, C++, to name a few, have long offered dynamic allocation of data objects both on the stack and in a separate area usually called the `heap` [Aho86]. The heap allocation of objects is utilized whenever the lifetime of these objects does not match the LIFO (Last-In, First-Out) allocation/deallocation behavior of a stack. In these languages, it is the responsibility of the programmer to deallocate data objects which are no longer in use, so that the storage they occupy can be reused for a new data object.

There is a problem, however. When pointers/references to a data object are stored in other data objects, it may be quite difficult for a programmer to make sure that a data object is no longer in use before he or she deallocates it. This problem is particularly severe in large applications which have developed over a number of years with a large number of programmers and which interface to software for which the programmer may not have access to the source code. As a result, a programmer may inadvertently deallocate an object which is still in use and subsequently reuse this storage for another purpose. When the deallocated object is referenced again, the application will usually fail--sometimes in a catastrophic manner. This problem is known as the `dangling pointer` problem.

One attractive solution to the dangling pointer problem is to move the responsibility of deallocation from the programmer to the programming language implementation. The parts of the system which take on this responsibility are often called automatic memory managers or garbage collectors. A garbage collector operates by looking at all of the application program variables which are directly accessible, and then following all chains of pointers from these variables to objects in the stack and the heap. Any object found in this way is called `accessible`, because it can conceivably be accessed by the application program by following a finite chain of pointers from a directly accessible program variable. The storage for inaccessible objects can then be reclaimed for reuse. Alternatively, the accessible objects can all be copied and relocated to a new area of memory, and the entire old area can then be reused for a new purpose. Such an automatic memory manager or garbage collector is said to implicitly deallocate inaccessible objects.

The art of automatic memory management and garbage collection is quite advanced. [Cohen81], [McEntee87], and [Bekkers92] review some of this art.

Stack-oriented computer languages are not inconsistent with implicit storage deallocation and garbage collection--e.g., the Algol-68 computer language offers garbage collection--but few implementations offer it. The most popular stack-oriented computer languages--e.g., Pascal, Ada, C, C++, to name just a few--do not utilize implicit storage deallocation and garbage collection, and therefore applications programs written in these languages run the risk of creating `dangling references` and thereby causing catastrophic software failures called `crashes`. The number of crashes in commercially distributed software due to these dangling references is testimony to the ubiquity and seriousness of this problem.

There are two major problems in retrofitting garbage collection into a stack-oriented language. The first is in tagging all of the data objects so that the garbage collector can know the boundaries of the object, as well as finding and tracing all of the pointers within the data object. The second is in finding all of the directly accessible program variables or `roots` for the garbage collection. Some of these program variables are global and/or static, and are not usually difficult to locate and identify to the garbage collector. The more difficult problem is that of locating and identifying the program variables that have been allocated on the stack, but for which a map to their location has not be provided by the compiler.

One general approach to these problems has been called `conservative` garbage collection [Boehm88] [Bartlett88]. Conservative garbage collectors do not attempt to precisely locate and identify all of the program variables or accessible objects, but only guess at their locations. These collectors are conservative, in that they attempt to err on the side of conservatism, in that any bit pattern that looks like it might be a pointer is assumed to actually be a pointer. A conservative garbage collector will treat the entire stack area as a source of `ambiguous roots` [Bartlett88], and any storage location which is pointed at by a suspected pointer is considered to be an accessible object if it is located in one of the storage areas in which accessible objects can be found. Suspected pointers found within `objects` located in this manner are also traced by the conservative garbage collector, in case the suspected object really is accessible to the running program.

Conservative garbage collectors have two significant problems. The most common problem is that their conservatism causes them to consider too much storage as accessible. Some researchers [Zorn92] have found that a conservative garbage collector may be less efficient because it may `hold onto` significantly more storage than a more precise collector would. It may also incur a greater cost in scanning time due to its imprecise knowledge about where accessible pointers are to be found. A less common, but more troubling problem, is that a conservative collector may fail to be conservative, and may miss some accessible objects, possibly due to aggressive compiler optimizations [Chase88]. Since an object which is accessible to the program, but is not considered accessible to the conservative garbage collector, will eventually be reallocated for a new purpose, a `conservative` garbage collector may actually cause a crash due to a dangling pointer in a program that would have operated correctly without the conservative collector. Although the known occurrences of dangling reference problems with conservative garbage collectors are very rare, the mere possibility of such problems raises serious doubts about the usability of this form of garbage collector for many applications.

The art of directly implementing advanced language features like tail recursion, first-class continuations and garbage collection in machine (or machine-like) languages is well-advanced. [Hanson90] is a recent review of some techiques of tail recursion; [Clinger88] is a review of some techniques of first-class continuations; and [Bekkers92] includes reviews of some techniques for garbage collection. Appel's approach to the Standard ML of New Jersey implementation [Appel88] [Appel89] [Appel0] [Appel92] of the ML programming language [Milner90] is particularly elegant and efficient.

Unfortunately, compilers which target machine languages are expensive and time-consuming to build, and with the increased complexity of generating code for highly pipelined RISC architectures, compilers targeting machine language will become even more expensive. Thus, the costs of supporting a language implementation on a wide variety of different instruction set architectures are growing quickly. This trend has caused a tendency for machine vendors to provide one or two compilers which directly target machine code--usually C and Fortran--and those wishing to support advanced languages such as Scheme or ML will seriously consider building compilers which translate those languages into C or Fortran, so that their language implementation will remain portable over a wide variety of instruction set architectures.

Although portability (and hence lower cost) is the major advantage for compilers to target languages like C or Fortran instead of machine language, there are other advantages. There are significant execution efficiencies to be gained through proper `instruction scheduling` of complex pipelines, and since the existing C and Fortran compiler vendors already have enormous incentives to provide these difficult optimizations, a compiler which targets C or Fortran instead of machine code can `piggy-back` on these efforts to gain the advantages at very low cost. There are also a substantial number of development and debugging tools available for C and Fortran programs that may not be available for machine language programs, so additional leverage is gained for these purposes. Finally, a large number of third-party subprogram `packages` already exist in C or Fortran--e.g., for computing transcendental functions--and the compiler targeting C or Fortran can utilize these, as well.

So some of the options facing the writer of an application which requires advanced computer language features such as tail recursion, first-class continuations, and/or garbage collection is to either 1) find an advanced language implementation of a language like Scheme or ML which compiles directly into native machine code for his chosen hardware processor; or 2) program his application in a less-advanced stack-oriented language such as C; or 3) write a Scheme or ML compiler which compiles directly into native machine code; or 4) write part or all of his application in assembly language for the native machine code. Options 1), 3) and 4) are very expensive, and option 2) is very difficult, error-prone, and most likely very non-portable.

Some of the options facing the writer of a compiler for a language having advanced features are 1) compile directly into native machine code, or 2) target an existing efficient implementation of C or Fortran. Option 1 can result in very efficient execution performance, but is very expensive. Option 2 can, and has been, done, but has significant problems of its own.

There are major problems implementing programs requiring tail recursion, first-class continuations, and garbage collection in a stack-oriented language like C that does not already have these features. Implementing tail-recursion can sometimes be done by converting the recursion into iteration, which can only be done within a single `block` compilation unit, and sometimes not even then [Bartlett89]. A more general method for achieving proper tail recursion in a stack-oriented language uses a trampoline, also called a dispatch loop. A trampoline is an outer function which iteratively calls an inner function. The inner function returns the address of another function to call, and the outer function then calls this new function. In other words, when an inner function wishes to call another inner function tail-recursively, it returns the address of the function it wants to call back to the trampoline, which then calls the returned function. By returning before calling, the stack is first popped so that it does not grow without bound on a simple iteration. Unfortunately, the cost of such a trampoline function call is 2-3 times slower than a normal subprogram call, and it requires that arguments be passed in global variables [Tarditi90]. Another alternative is to tamper with the C compiler itself, but this alternative is also not portable.

Implementing first-class continuations on top of a stack-oriented language like C typically requires non-portable machine language access to the details of the stack format [Bartlett89]. Furthermore, many mutable objects such as assignable cells cannot be allocated on the stack due to the multiplicity of copies of the stack that can exist, so some optimizations are impossible to perform [Clinger88].

Implementing garbage collection on top of a stack-oriented language like C requires either the use of a secondary stack [Yuasa90] [Chailloux92] and/or the use of a conservative garbage collector [Boehm88] [Bartlett88], which may be both inefficient and insecure. Discussions of additional references are attached hereto in Appendix B ("Additional Related Art"). References from Appendices A, B, and C are incorporated by reference herein.

In summary, to utilize and/or compile advanced language features such as tail recursion, first-class continuations, or garbage collection, we have either Appel's elegant, efficient and expensive method of utilizing native machine language [Appel88] [Appel89] [Appel90] [Appel92], or we have cheaper methods of using stack-oriented languages like C which are crude, complex, and potentially catastrophic [Bartlett88] [Bartlett89] [Boehm88] [Tarditi90] [Chase88]. The existing art tries to either ignore the stack [Sussman75] [Appel90] [Tarditi90], or to utilize the normal Last-In, First-Out (LIFO) behavior of the stack as much as possible through complex optimizations [Steele78] [Bartlett89] [Tarditi90].

There accordingly exists a need for an improved method to utilize and/or compile advanced language features such as tail recursion, first-class continuations, and garbage collection which is both efficient and reliable ("crash proof"), and cost effective to implement.

The present invention makes use of the stack in a stack-oriented language to implement the desired advanced features, but in a novel way. The present invention makes use of the advantages of allocating storage for frames and objects on the stack, but does not normally deallocate storage from the stack, except under the control of a garbage-collection-like process. In this way, the dangers of unsupervised stack deallocation are eliminated, yet many of the advantages of using the stack are realized.

[Fischer72] describes the conversion of a program to continuation-passing style (CPS) for execution on the stack of a stack-oriented language for the purposes of a theoretical proof. He also comments that "a consequence of the above theorem is that free [heap] storage may be saved at the expense of increased use of the stack. In the absence of CONS [which allocates heap storage], the stack must grow arbitrarily large . . . ". Over twenty years passed before the present invention provided a solution to this problem of an arbitrarily large stack for the execution of continuation-passing style in a stack-oriented language.

The present invention utilizes the well-known technique of converting a program to continuation-passing style (CPS). If this CPS program is executed directly in the stack-oriented language implementation, the stack will grow and overflow its preassigned storage area. In the case of this stack overflow, the present invention solves this problem by utilizing a copying garbage collector process to evacuate any accessible data objects from the stack to the heap, after which the entire storage area of the stack may be reclaimed by contracting the stack, and the program restarted with the now-shortened stack.

Since in the practise of this invention the stack is usually given a predetermined fixed size, then the benefits of the decreased storage requirements of tail-recursion optimizations are achieved because only a small amount of accessible data will be relocated out of the stack when the stack is evacuated. The feature of first-class continuations is immediately available as the result of converting to continuation-passing style [Appel92, p. 135]. Finally, the ability to precisely determine accessible objects for garbage collection is also immediately available as the result of converting to continuation-passing style and representing continuations and closures as first-class data objects [Appel92, p. 135].

One aspect of the invention provides a method for executing an advanced application, said application comprising a number of related subprograms implemented in a stack-oriented language which includes both a stack and a heap, comprising the steps of:

converting one or more of said application subprograms into continuation-passing style (CPS) in the stack-oriented language;

determining the extent and limit points of a stack buffer on the execution stack of the stack-oriented language, which buffer is capable of holding a plurality of invocation stack frames;

commencing the execution of the application such that the initial invocation stack frame is within the limits of the stack buffer;

interrupting any of said CPS-converted subprograms when the execution stack pointer is beyond a limit point of the stack buffer;

initiating an evacuation process to transport out of the stack buffer into the heap any live data objects found in the stack buffer;

contracting the execution stack of the stack-oriented language back to the beginning of the stack buffer; and

resuming the execution of the interrupted CPS-converted subprogram.

Another aspect of the invention provides a method for executing one or more mutually recursive subprograms implemented in a stack-oriented language which includes both a stack and a heap to achieve the benefits of tail recursion, comprising the steps of:

converting the subprograms into continuation-passing style (CPS) in the stack-oriented language;

determining the extent and limit points of a stack buffer on the execution stack of the stack-oriented language, which buffer is capable of holding a plurality of invocation stack frames;

commencing the execution of the mutually recursive subprograms such that the initial invocation stack frame is within the limits of the stack buffer;

interrupting a CPS-converted subprogram when the execution stack pointer is beyond a limit point of the stack buffer;

initiating an evacuation process to transport out of the stack buffer into the heap any live data objects found in the stack buffer;

contracting the execution stack of the stack-oriented language back to the beginning of the stack buffer; and

resuming the execution of the interrupted CPS-converted subprogram.

Yet another aspect of the invention provides a method for executing one or more subprograms of an application implemented in a stack-oriented language which includes both a stack and a heap to achieve the benefits of first-class continuations, comprising the steps of:

converting the subprograms into continuation-passing style (CPS) in the stack-oriented language so that continuation closure objects are local stack-allocated objects;

determining the extent and limit points of a stack buffer on the execution stack of the stack-oriented language, which buffer is capable of holding a plurality of invocation stack frames;

commencing the execution of the mutually recursive subprograms such that the initial invocation stack frame is within the limits of the stack buffer;

capturing one of the stack-allocated continuation closure objects;

interrupting a CPS-converted subprogram when the execution stack pointer is beyond a limit point of the stack buffer;

initiating an evacuation process to transport out of the stack buffer into the heap any live data objects including live continuation closure objects found in the stack buffer;

contracting the execution stack of the stack-oriented language back to the beginning of the stack buffer; and

resuming the execution of the interrupted CPS-converted subprogram.

Yet another aspect of the invention provides a method for executing one or more subprograms of an application implemented in a stack-oriented language which includes both a stack and a heap and a further garbage collector for said heap to achieve the benefits of precise garbage collection, comprising the steps of:

converting the subprograms into continuation-passing style (CPS) in the stack-oriented language so that continuation closure objects are local stack-allocated objects;

determining the extent and limit points of a stack buffer on the execution stack of the stack-oriented language, which buffer is capable of holding a plurality of invocation stack frames;

commencing the execution of the mutually recursive subprograms such that the initial invocation stack frame is within the limits of the stack buffer;

interrupting a CPS-converted subprogram when the execution stack pointer is beyond a limit point of the stack buffer;

initiating an evacuation process to transport out of the stack buffer into the first generation of a garbage-collected heap any live data objects including live continuation closure objects found in the stack buffer;

contracting the execution stack of the stack-oriented language back to the beginning of the stack buffer; and

resuming the execution of the interrupted CPS-converted subprogram.

The present invention provides methods for achieving advanced language features--i.e., tail recursion, first-class continuations and garbage collection--in a stack-oriented language.

One aspect of the invention is to provide the benefits of a tail-recursion optimization in a stack-oriented language which may not already offer such an optimization.

Another aspect of the invention is to provide the benefits of a tail-calling optimization for mutually recursive subprograms in a stack-oriented language which may not already offer such an optimization.

Another aspect of the invention is to provide the benefits of a tail-calling optimization for mutually recursive subprograms which are separately compiled in a stack-oriented language which may not already offer such an optimization.

Another aspect of the invention is to provide the benefits of a tail-calling optimization for mutually recursive subprograms without requiring complex analyses of the application utilizing such mutually recursive subprograms.

Another aspect of the invention is to provide the benefits of a tail-calling optimization for mutually recursive subprograms without requiring the block compilation of these subprograms.

Another aspect of the invention is to provide for garbage collection in a stack-oriented language which does not already offer garbage collection.

Another aspect of the invention is to provide for the precise (unambiguous) location of roots for garbage collection in a stack-oriented language which does not already offer garbage collection.

Another aspect of the invention is to provide for an efficient implementation of first-class continuations and continuation capture in a stack-oriented language.

Another aspect of the invention is to provide a simple and elegant method of compiling a language with advanced features such as tail-recursion, first-class continuations and garbage collection into a stack-oriented language which may not offer those advanced features.

Another aspect of the invention is to provide a simple and elegant method of compiling a language with advanced features such as tail-recursion, first-class continuations and garbage collection into a separate compilation units of a stack-oriented language which may not offer those advanced features.

Another aspect of the invention is to provide a simple and elegant method for safely allocating assignable cells, subprogram closures, and other objects on the stack of the stack-allocated language in such a way that they are relocated from the stack prior to the stack storage being reallocated for another use, and thus avoid `dangling pointers`.

Another aspect of the invention is to provide a method for safely allocating assignable cells, subprogram closures, and other objects on the stack of the stack-allocated language without requiring complex compile-time analysis of the application which allocates said assignable cells, subprogram closures, and other objects.

The present invention teaches methods of implementing an application utilizing advanced features such as tail-recursion, first-class continuations, and/or garbage collection in a stack-oriented language that may not offer these advanced features. In particular, the present invention teaches methods of compiling an application written in a language having such advanced features into a stack-oriented computer language.

The method of the invention for implementing these advanced features involves converting one or more of the application subprograms into continuation-passing style (CPS) [Appel92] in such a way that some of the objects requiring storage allocation --e.g., assignable cells, subprogram closure records and other objects--are allocated as variables local to the current stack frame in the subprogram after being CPS transformed and translated into the stack-oriented language. A CPS-transformed subprogram will never return, and hence will never release its stack frame on the execution stack of the stack-oriented language [Fischer72]. This stack will eventually exceed a bound imposed by the invention, at which time execution of the application will be suspended in order that a copying garbage-collection-like process can relocate any live data objects (assignable cells, subprogram closures, and other objects) into a more permanent heap storage area. When this relocation process has completed, the runtime stack of the stack-oriented language will no longer contain live data objects, and it is then contracted through the deallocation of stack frames. This contraction may be achieved either through the execution of a `longjmp` or `throw` type of non-local exit operator, or it may be achieved by simply returning from all of the frames which are currently allocated on the stack, one by one. After the stack has been contracted, the application program then resumes execution with the now-smaller stack.

As a specific example of the method, consider the compilation of a program in the Scheme programming language into a program in the C programming language. The invention first converts the Scheme program into continuation-passing style (CPS), as is well-known in the art [Steele78] [Kranz86], and then translates the resulting Scheme functions/lambda-expressions more-or-less directly into C functions, again well-known in the art [Bartlett89] [Appel92]. In the present invention, Scheme arguments are passed as normal C arguments, and Scheme function calls become normal C function calls. First-class continuation closures and closure environments are passed as extra C arguments. Such a continuation-passing C program will not normally execute a C return, so the C stack will grow and grow. Since the C stack will not normally contract with such a program, we can safely allocate all of our closures and user data objects/structures on this stack as automatic/dynamic/local data. All closures and user data objects/structures whose sizes are known at compile time can be statically allocated as local `automatic` variables in the C stack frame. If desired, dynamic arrays and other data objects/structures whose size is unknown at compile time may be allocated on the stack by the non-standard `alloca` primitive (or equivalent) found in some C implementations, or they may be allocated directly in the heap by C's `malloc` primitive (or equivalent).

In this simple CPS example, since none of the CPSC functions ever return, the only live frame on the C stack is the top one. However, since we have allowed many data objects to be stack-allocated as objects within a stack frame, there will be found within many of the dead frames accessible closures and accessible user data objects. Eventually, the C stack will overflow the predetermined buffer space allowed for it, and a first-generation copying garbage collection (GC) will be performed [Appel89]. There are a number of static roots already known to the GC, as well as the latest continuation closure which is passed to the GC as an argument. The live objects and live closures are all evacuated by being relocated (and thereby compacted) into a second generation heap area [Appel89] [Appel90], so that execution can be restarred via a C longjmp to a C setjmp at the beginning of the C stack.

A key point is that since only live frames and accessible objects are traced--i.e., the C frames, which are all dead, are not traced--The first-generation GC never has to know the detailed machine format of the C stack frame, and can therefore be written in portable C. This first-generation GC can also be called by explicit C code within each generated C function which checks if the predetermined limits of the C stack will be exceeded.

If the predetermined size of the C stack is a relatively small constant, the benefits of tail-recursion are obtained, because only a fixed number of garbage C stack frames can accumulate before they are reclaimed. The benefits of efficient first-class continuation capture are achieved because the continuation-passing style transformation makes always available a pre-packaged first-class continuation object for easy manipulation [Appel92]. Precise/unambiguous roots are available for use by the garbage collector because all roots are either static, or live arguments to the garbage collector; no live pointers remain on the C stack. Furthermore, these benefits are achieved even for portions of the program which are separately compiled, since our invention does not depend upon information propagating only within a single compilation unit such as happens with block compilation.

"subprogram", Often called a "subroutine", a "procedure", or a "function", depending upon the particular computer language.

"stack-oriented computer language". A computer language which allocates invocation frames on a last-in, first-out (LIFO) stack by allocating an invocation frame during a subprogram call and deallocating this invocation frame during a subprogram return. This LIFO stack may be implemented in a number of ways known to one skilled in the art, including the use of a continguously addressable range of computer memory and a stack pointer which is incremented and decremented. Other implementations of stacks may include the use of linked lists of frames. Examples of stack-oriented computer languages include the C [Kernighan88] [Harbison91] [Plauger92] and C++[Ellis90] [Stroustrup91] programing languages and their dialects, variants, extensions and successors.

"stack pointer". The invocation frames found on the stack of a stack-oriented computer language require that the processor keep at least one implicit pointer which points to the current such frame. This implicit pointer is call the "stack pointer", and may point the the beginning of the current frame, the end of the current frame, or some other convenient place relative to the current frame.

"application" A program consisting of a number of subprograms.

"live object". A data object that can possibly be referenced if the current program continues execution.

"accessible object". A data object that is either directly accessible to the program as a program variable (either static or dynamic), or can be reached from such a program variable by a finite sequence of pointers. Precise garbage collectors compute the set of accessible data objects. Under normal conditions, the set of accessible objects will include the set of live objects.

"garbage-collected computer language". A computer language in which storage allocation and deallocation is aided by a garbage collector (GC) which enumerates a number of roots and which locates and identifies the allocated storage which is accessible via a chain of pointers from these roots. A garbage-collected language may utilize the principles of a `conservative` GC and may not utilize precise root or object format information.

"continuation-passing style". A style of programming in which subprogram returns are implemented by means of calls to a further functional argument called a `continuation` which accepts the value(s) to be `returned` from the subprogram and uses these values and objects as parameters to complete the computation. Continuation-passing style is discussed in [Fischer72] [Steele78] [Kranz86] [Appel88] [Appel92].

"tail-call optimization" or "tail-recursion optimization". An optimization in which the last call in a subprogram body releases the storage for this subprogram's invocation frame so that this storage can be reused to construct the called subprogram's invocation frame. This optimization can be used to convert simple recursions (tail recursions) into iterations.

"first-class continuation". Many programming languages provide some of the features of continuations which perform non-local transfers of control. For example, the PL/I language provides a goto operator which may exit a number of functions in the process of transferring control. The C language provides the setjmp/longjmp pair which allows the non-local transfer of control which may exit a number of functions in the process. The C++ language provides the catch/throw pair which allows the non-local transfer of control, but in a way that `cleans up` the functions which it exits in the process. In the C and C++ languages, neither the setjmp nor the catch operations can `capture` the current state and package it up in the form of a first-class data object which may be passed as an argument, returned as a value, and stored into a variable. The PL/I language provides for the ability to store goto labels into variables, but there is no guarantee that the label will not become meaningless due to exiting the stack frame in which the label was defined. First-class continuations, as found in Scheme and certain implementations of other advanced languages such as ML, can perform the functions of PL/I labels, C setjmp/longjmp and C++ catch/throw, but many other functions, as well. Other names for first-class continuations are "reified continuation" and "captured continuation".

"advanced computer application". An advanced computer application is one involving one or more of the following advanced programming features--tail recursion, first-class continuations and garbage collection.

The methods of the present invention compile a Scheme program, for example, to C, for example, by converting the Scheme program into continuation-passing style (CPS), and then compiling the resulting lambda expressions into individual C functions. Arguments are passed as normal C arguments, and function calls are normal C calls. Continuation closures and closure environments are passed as extra C arguments. (Of course, calls to closures perform a C call on the code portion of the closure, and pass the environment portion of the closure as an additional argument.) Such a Scheme never executes a C return, so the stack will grow and grow.

Since the C stack never contracts, we can allocate all of our closures and user data structures on this stack as automatic/dynamic/local data. All closures and user data structures whose sizes are known at compile time are statically allocated in the C stack frame; dynamic arrays and other data structures whose size is unknown at compile time can be allocated by the non-standard alloca primitive (or equivalent) available in some C implementations, which also obtains space from the C stack, or it may allocate such objects directly on the heap.

Since none of our C functions ever returns, the only live frame on the stack is the top one. However, within many of the dead frames will be found live closures and live user data objects. Eventually, the C stack will overflow the space assigned to it, and we must perform garbage collection to reclaim the space on the stack by copying the live objects off the stack into the heap.

Garbage collection (GC) by copying is a relatively straightforward process. There are a number of static roots, as well as the latest first-class continuation closure, which is passed to the GC as an argument. (Forming an explicit first-class continuation closure object for the GC avoids the necessity of scanning C stack frames.) The live objects and live closures are all copied (and thereby condensed) into another area, so that execution can be restarred with a "stack" frame at the beginning of the C "stack" allocation area.

A key point is that since only live objects need be traced by the GC--i.e., garbage (including the C frames, which are all dead) is not traced--the GC does not have to know the format of a stack frame and can be written in portable C. A Cheney-style scanner [Baker78] must know the format of all tospace objects, but we copy only first-class objects--never C frames. When the GC has finished evacuating the live objects from the stack to the heap, it returns to a frame at the base of the stack to continue execution. The GC may be called explicitly from the C code after checking whether the stack pointer has reached its preset limit. Although stack-pointer checking in this way may require a few more instructions than if it were done in assembly language, it is still faster than a trampoline call would be.

The following simplified code demonstrates how an environment object and a first-class continuation object may be passed to a constructed C function, how objects may be allocated within the local stack frame of this function, how the stack can be checked for overflow, and how the garbage collector can be called with the constructed first-class continuation object.

After the GC is done copying, it must reset the C stack pointer to the beginning of the allocation area and call the continuation argument that was passed to the GC function itself. Since the GC itself has been executing out of its frame on the stack, the GC must cause the stack pointer to be reset to the base of the stack and then call the GC's continuation argument. After the live data has been copied elsewhere--this is a minor collection in the terminology of generational garbage collectors--the GC can execute a C longjmp operation to a C setjmp `trampoline` and the setjmp can restart the continuation with the stack pointer allocating at the bottom of the stack again. Later, when the total copied data in the second area exceeds a certain amount, a major collection is performed on the second area; the second area may utilize either another copying GC, or could conceivably use a totally different kind of storage management or GC strategy from the copying GC strategy used for the stack.

An alternate (and portable) way to reset the stack pointer is for the GC to simply return, which will cause all of the functions having frames currently on the stack to also return, one by one. Since these returns do nothing but reset the stack pointer, they will not interfere with the data which has already been evacuated to the heap. The `trampoline` in this case is a driver function which takes the continuation argument given to the GC, and then starts executing it to resume the application's computation.

Another way besides longjmp/setjmp to relocate the stack pointer is for the GC to call a (non-standard) `alloca` function with an argument which is the difference between the current stack pointer and the desired stack pointer. Then, the GC can call its continuation.

In the preferred embodiment, most object construction is initially done using stack-allocated (dynamic) local storage. This is because stack-oriented languages are optimized for operations on stack-allocated local objects. Thus, the revappend function to reverse one list onto another list looks like the following code. The appearance of the C return statement is curious, since the revappend function doesn't actually ever return. This return signals the C compiler that the local variables are all dead except for possibly the return address, and therefore the C compiler need not save those values "across" the recursive call to revappend.

The following code illustrates how one tail-recursive subprogram could be implemented (in this example, the stack overflow checking has been left out for greater clarity).

Closure objects, whose size are always known by the compiler, can be explicitly constructed in the local frame in a similar manner. Vectors and arrays whose size is unknown at compile time can be allocated by calling a non-standard alloca function (or its equivalent) to extend the current stack frame. (See also the section below on malloc-allocated objects.)

Appendix C illustrates the basic elements of the invention. A standard Lisp benchmark program called Boyer [Gabriel85] has been translated by hand into ANSI C using the teachings of this invention. The resulting program is called CBoyer, and has been tested on a number of different computer architectures. The program allocates a stack buffer of predetermined size, as well as a large heap. Since this program is intended to be illustrative of the present invention, and since the principles of generational garbage collection are well-known [Bekkers92], we have not included a garbage collector for the secondary heap in this particular example program.

This CBoyer program includes a number of C macros which compute certain primitive predicates, define certain symbols, and compose and decompose certain structures--including closure structures. On Appendix C, page 7 are defined global variables which after initialization will define the boundaries of the stack buffer, as well as hold the first-class continuation closure during the operation of the first-generation garbage collector. The Boyer benchmark program itself begins on Appendix C, page 10. The garbage collector functions occupy Appendix C, pages 14-15, and are quite classical [Baker78]. The driver program `main.sub.-- main` for the Boyer benchmark occupies Appendix C, pages 16-22. main.sub.-- main first initializes the exit first-class continuation object at Appendix C, page 16, lines 705-706. At Appendix C, page 22, lines 982-983, a first-class closure created holding the initial function to call. After setting up the stack buffer it initializes a large number of data structures needed by Boyer. It then allocates the storage for the heap which forms the second generation. Finally, at Appendix C, page 22, line 1013, it sets up the setjmp, and starts the initial function of the Boyer program with the exit first-class continuation previously set up. Whenever the stack buffer is determined to have overflowed (see Appendix C, page 4, line 148), the garbage collector GC starting at Appendix C, page 15, line 649 will be called. After evacuating live objects from the stack buffer, the GC will execute the longjmp at line 685, which will take it back to page 22, line 1013, as well as contract the stack.

We note that this Cboyer program does not check for stack overflow on every call, but checks for overflow only for those calls when a subprogram's continuation is called (Appendix C, page 4, lines 145-153.). This illustrates that the invention does not depend on a firm limit for the size of the stack buffer, but this limit can be exceeded from time to time, so long as the extent of the excess is bounded by a relatively small amount. This freedom allows for more efficiency in the code which checks for stack overflow. Of course, if the stack buffer is implemented as a hardware buffer, for example as a primary cache in an advanced microprocessor, then the checking for overflow would have to be more strict.

The following sections deal with some additional details of the method of the invention.

In the preferred embodiment, the stack of the stack-allocated language acts as the first generation of a generational garbage collector [Appel89]. Following [Appel89], we protect this generation with a write barrier. This means that if a pointer into the C stack is about to be written into a location outside the C stack, then a record of this is made in a vector or list especially constructed for this purpose. Since writes of this type are expected to be relatively rare--e.g., the application program exhibited in Appendix C does not require any such writes --the construction of such a record will not place a great burden on the executing program. This list becomes a source of additional roots for the first generation garbage collector which evacuates live objects from the stack of the stack-allocated language. There are many other possible implementations of such a generational write barrier known to one skilled in the art.

In the preferred embodiment, the heap itself may consist of one or more additional generations of a generational garbage-collected heap [Wilson92]. Similar copying garbage collection processes and write barriers can be utilized for these additional generations.

The heap of an alternative embodiment may use a different storage management and garbage collection technique from the copying one utilized for the first generation on the stack of the stack-oriented language. For example, this second generation heap could be the last generation with no further generations, and may be an `in-place`, rather than a copying, type of garbage collector.

A further alternative may use a heap with no further garbage collection whatsoever. The application may be such that the first generation filters out enough of the objects with very short lifetimes that no further storage reclamation may be required.

This implementation of call/cc is trivial in continuation-passing style (CPS) [Appel92], since first-class continuations are being constructed and passed on every function call. Capturing such an already-constructed first-class continuation object simply requires that the object be referenced.

Variable-arity Scheme functions may be compiled into variable-arity C functions using either the Unix varargs or the ANSI C stdarg mechanism [Kernighan88] [Harbison91] [Plauger92]. With the continuation-passing style of the method, not only are multiple returned values easily handled as multiple arguments to the continuation, but variable-arity multiple "returned" values can also be handled using variable-arity continuations.

Scheme compilers perform a great many optimizations to ensure the efficiency of tail recursions. When using the local stack allocation taught as part of the present invention, the definition of an `iterative` routine is narrowed considerably--only those iterations which do no storage allocation may be easily converted into an iteration, because the storage for most objects is allocated on the stack. In particular, only the lowest-level functions can operate without allocating some storage--e.g., calls to C library routines that restore the "stack" pointer can be made within an iteration. Local tail-recursion optimizations [Bartlett89] are thus sufficient to obtain efficient iteration. We thus achieve the spirit, if not the letter, of ANSI Scheme's tail-recursion law [Scheme90].

Scheme compilers perform a number of optimizations to reduce the cost of closure creation and the cost of function calling--e.g., they take advantage of "known" functions when compiling function calls..sup.1 "Lambda lifting" [Peyton-Jones87] can be used to replace closure creation by means of additional argument passing; this optimization is very valuable when arguments can be kept in registers. [AppelShao92] discusses other ways to keep variables in machine registers; these same techniques can be useful for C programs in conjunction with the present invention, as well. [Appel92] discusses a number of optimizations which are valuable in conjunction with the present invention. Various kinds of type inference can be used optimize the representation of values and avoid the need for run-time type checks. Most optimizations continue to be valuable in conjunction with the present invention --i.e., they are orthogonal to the policies of memory management.

Other common Scheme optimizations include the generation of assignable cells [Kranz86] which allow more flexibility in the implementation of closures and continuations. Further optimizations may directly incorporate these assignable cells without closures and continuations under certain conditions. The present invention can always simply allocate assignable cells within the local stack-allocated frame. If the cell must later be relocated to the heap, it will be transported by the same garbage-collector mechanism that evacuates all live objects from the stack --no distinct mechanism is required.

If malloc-allocated storage is distinguishable by address range from the stack/heap storage, then malloc may be used to allocate (non-relocatable) objects. Portable implementations may prefer malloc to alloca for objects whose size is not known at compile time. These objects must be enumerable, so that the GC can first trace these objects (they must have proper tags), and then sweep and explicitly free those objects which have become garbage.

In order to obtain proper tail-recursion, existing Scheme-to-C and ML-to-C compilers do large amounts of interprocedural optimizations (including block compilations) which interfere with separate compilation, create large C functions, and cause long C compilations. In the methods of the present invention, the benefits are achieved even for separately compiled functions, because every C function which is generated by the conversion to continuation-passing style can in principle be placed into a different file and separately compiled.

Calling normal (non-continuation-passing) C functions which return is trivial, except that you must assure enough "stack" space in advance so that the C "stack" does not overflow during the execution of these normal C functions. These C functions cannot store pointers to GC-able objects, except in "root" locations already known to the garbage collector, nor can they "call back" to continuation-passing-style C functions.

If such "call-back's" are required for the application, then a solution is to provide two separate C stacks--one for normal functions, and one for continuation-passing-style functions, and switch to the appropriate stack when calling a function of the other kind. This switching of C stacks can be implemented very portably by utilizing setjmp and longjmp operations in a manner analogous to the implementation of multiple processes described in [Wand80] and since implemented similarly in C. In other words, if a CPS function calls a CPS function, then it continues to use the CPS stack, whereas if a CPS function calls a normal function, then it makes the call on the normal stack. Finally, if a normal function calls a CPS function, then it makes the call on the CPS stack. Any evacuation of the CPS stack will evacuate the entire stack buffer, but this is okay, since there are only live objects, but no live stack frames, in the CPS stack buffer.

The present invention has good performance on most architectures on which copying garbage collection is efficient. The one known exception to this is the Sun Microsystems `SPARC` architecture, which utilizes a technique known as `register windows`. This architectural feature was developed with the presumption that bursts of stack pushes and bursts of stack pops would be rare. This presumption is incorrect for the present method, and therefore this architectural feature must be bypassed or neutralized. One solution to this problem is to compile the continuation-passing style (CPS) C program into assembly language, and then use a simple program to edit this assembly language to remove instructions which manipulate these register windows. Although this solution is very crude, it has tremendous benefits on the common SPARC architecture--the example program of Appendix C, as modified by the assembly editing program, ran three times (300%) faster than the unmodified output of the GNU C compiler for the SPARC architecture.

The lack of tail recursion in C may be an advantage for implementing a tail-recursive, garbage-collected language like Scheme which has first-class continuations. If all functions are transformed into continuation-passing style, if arguments are passed as C arguments (even for variable-arity functions), if C's "stack" allocation is used to perform all allocation (including closure allocation), and if a copying garbage collector is used, then a Scheme implementation on top of C which is similar to the implementation of SML/NJ [Appel92] can be achieved, except that it will be much more portable. In the present invention, the entire C "stack" is effectively the youngest generation in a generational garbage collector similar to that of SML/NJ.

A key feature of the invention is that the garbage collector avoids the necessity of tracing garbage, and therefore it need not know the format of this garbage, which includes all of the C stack frames. At the cost of continually checking and following forwarding pointers, the present invention can be made "real-time" [Baker78]. A previous paper [Baker92] also advocated allocating objects on the stack within the local stack frame. However, the current scheme is simpler, since it does not require that objects be forwarded dynamically during execution.

Many other modifications, variations and extensions of the invention will be apparent to those skilled in the art from the above description. In many areas, a number of options are available for implementing a given feature, and the choise of an implementation depends on specific design factors.

Although the invention has been described in relation to various implementations, together with modifications, variations and extensions thereof, other implementations, modifications, variations and extensions are within the scope of the invention. The invention is therefore not limited by the description and attached appendices contained herein, but only by the claims. ##SPC1##