Path: utzoo!attcan!uunet!husc6!uwvax!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson
From: wilson@uicbert.eecs.uic.edu
Newsgroups: comp.lang.lisp
Subject: modifying KCL memory scheme
Message-ID: <63200002@uicbert.eecs.uic.edu>
Date: 21 Nov 88 21:17:00 GMT
Lines: 40
Nf-ID: #N:uicbert.eecs.uic.edu:63200002:000:1564
Nf-From: uicbert.eecs.uic.edu!wilson    Nov 21 15:17:00 1988


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