[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Leakiness and Kernels
The Perq implemenation of Common Lisp weighs in at 2.5 megabytes as it
sits out there on the disk. That includes the Compiler, the Hemlcok
text editor, debugging aids, documentation strings, and all of Common
Lisp. For just the language itself, and flushing the doc strings, I
think we'd come in at a megabyte or maybe somewhat less, but of course
you would not want to use such a system.
There's a lot of stuff in Common Lisp that doesn't have to be there --
hyperbolic arctan, Roman numeral output in Format, etc. We put that
stuff in because most of the designers felt that, starting now, any
machine without virtual memory is not interesting for serious work.
Given that people were going to add these things anyway, we figured that
they may as well be built in so that they are done in a standard way.
Of course, the last generation of microcomputer chips (and the current
generation of low-end personal computers) does not support virtual memory.
Any Common Lisps on them will have to either go for a subset or get very
clever about overlays and such. But this is a temporary phase that
won't be with us for long, and it seemed a shame to ruin the language in
order to accommodate these transitional machines.
Storage-management is completely up to the implementation, but in my
opinion any implementation that leaks storage at all is broken. A
Xerox-style reference-count GC is OK as long as it is backed up with a
real garbage collector, but not otherwise. Most Common Lisp
implementations will use some sort of copying GC, since strings and
other ragged-length data structures are so important in this language.
In GC's of this sort, there is no reason for any leaking -- it's easy
enough to do it right.