wilson@uicbert.eecs.uic.edu (11/22/88)
Has anybody out there mucked with Kyoto Common Lisp's memory management?
I'm considering implementing a generational garbage collector for it,
and am trying to assess the difficulty of this project.
(My goal is to build an instrumented collector that will gather
statistics about survival, locality of reference, and locality
of state changes. I'm considering doing it for T, but if it
isn't much harder, I'd rather do it for a Common Lisp because of
the greater availability of programs to gather statistics on. If
anybody has another Common Lisp that would be more appropriate without
a major cost for a source license, please contact me.)
As I understand it so far, KCL uses a sort of BIBOP scheme, which I
would want to change so that I can use location to encode age, rather
than type.
For anyone who knows KCL's innards, two questions:
1. How modular is the memory scheme, really? Are there
hidden dependencies on data formats? (Or on objects
not being moved by the collector, as mine would do?)
2. What else would have to be done? (For example, modifying
the code generator to emit code to record intergenerational
references; how hard would that be?)
3. What kind of difficulties would I encounter in making
such low-level changes and rebuilding the system, repeatedly?
Thanks prematurely,
Paul
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680 jbn@glacier.STANFORD.EDU (John B. Nagle) (11/23/88)
One might want to do this because it's cool, but it's not terribly useful to do so. The classic mark/sweep algorithm used in KCL is quite effective in that environment, simply because compilation and editing take place in other address spaces, and so the workspace does suffer massive garbage transients induced by compilation. The compiler runs as a separate LISP image, and seldom garbage collects; the process exits and the space is released. Editing is entirely outside the LISP environment. Overall, this appears to be not significantly worse than the big all-in-one environments, like Lucid's, at least as of summer, 1987. John Nagle
wilson@uicbert.eecs.uic.edu (11/29/88)
My interest is in fact because it's cool, research-wise. I am
interested mostly in gathering data, so instrumentation is actually
more important than efficiency. I also want to explore techniques
for advancement and scavenge scheduling, to improve efficiency and
to avoid disruptive pauses.
Also, it would seem that big, serious programs allocating a lot
of data would start to show the shortcomings of any mark-and-sweep
collector. Does anybody have such programs running in KCL? Those
are the ones I want to gather statistics on; others are too easy.
-- Paul
Paul R. Wilson
Human-Computer Interaction Laboratory
U. of Illin. at C. EECS Dept. (M/C 154) wilson%uicbert@uxc.cso.uiuc.edu
Box 4348 Chicago,IL 60680