Browse Theses

We have analyzed four large Lisp programs running in a Common Lisp system on a conventional processor to provide information useful for implementers of new Lisp systems. The execution of over fifty million Lisp function calls (over one billion host instructions) are represented in the results. We address some possible implementation tradeoffs and provide pertinent empirical information. Among the issues discussed are data tagging techniques, quantity of tags, time and space efficient representations for Lisp data types, methods of function linkage, the nature of variable access, the use of tail-recursion and non-local goto's, and garbage collection. Our findings indicate that for many conventional processors choices should include a small number of tag values encoded in the low-order bits of a data reference, a simple "car followed by cdr" organization for CONS cells, and an encoding of symbols which segregates the different fields.

Garbage collection frequently represents a sizable portion of overall execution time. The new "generation" garbage collectors can provide dramatic performance improvements, but require the maintenance of entry vector and data age information. To maintain the entry vector, previous generation collectors have included runtime tests (generation checks) at each tagged store operation. For our Lisp system the cost of these checks in software is projected to be at least 7% of runtime.

We describe a new version of generation garbage collection adapted for Lisp on conventional processors. Our version eliminates generation checks during normal execution: information maintained by the virtual memory system is used to construct the entry vector. A simple memory layout is employed which does not require storage for age information (other than one value per generation) and allows adjustment of the boundaries between generations to avoid fragmentation and maximize memory utilization in implementations with limited memory. An analysis of the new algorithm on the test system showed that, when collections were separated by more than 1.4 seconds (or at least 160 kilobytes of new allocation), using virtual memory information required less time than software generation checks.