GC, exit-to-system

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

My experience with large portable programs that GC a lot suggests that trying
to make a portable GC abstraction doesn't work for reasons related not only
to what kind of GC is involved but also because of time requirements. eg,
sometimes you want to call GC because you're about to dump a system and maybe
then you don't care how long it will take. other times, you are calling it just
because you learned to program in Maclisp where GC'ing was so fast you didn't
care. eg, Maclisp GC was fast enough that although it would have slowed things
down slightly, you could almost have gotten away with calling it every time
you thought there might be garbage to collect. That certainly isn't true for
some GC's I've run into. eg, if they take more than 5 seconds, I may not be
willing to wait. Certainly if they take more than a minute, I am not willing to
wait. Also, implementations differ in whether there will be garbage to collect.
If you have the ephemeral GC running on the 3600, there may not be any point
to trying to GC because the ephemeral GC is working well enough.

What I'm getting at is that my initial reaction is that what I was doing
was saying
 (DEFUN GC ()
   #+3600 NIL
   #+ABC  (GC)
   #+DEF  (SYSTEM:GC-INTERNAL T NIL 3)
   #+GHI  (GC:DO-IT)
   ...)
but that I've found from experience that although I know what GC people would
have provided me, I'm not happy with the performance of those GCs -- not in
the sense that they don't do reasonable things, but in the sense that they
do anything even remotely comparable. Each one was written by an implementor
who had certain priorities in mind. eg, the folks on micros probably have fast
GC's so they like to be able to call them, but the folks on machines that have
big disks and big virtual memory areas and bad paging performance are in a
different boat. 

In fact, I should underscore the fact that I'm sufficiently content with making
(GC) just do nothing on the 3600 as long as the ephemeral GC is running that I'm
really not trying to say that Symbolics somehow would be the one to suffer for
this decision. I'm wearing my portable-code-writer's hat when I insist that
I might want a GC that let me have all sorts of hairy keywords that said things
like
  (GC :UNLESS-THERES-LOTS-OF-FREE-MEMORY T
      :UNLESS-IT-WILL-TAKE-LONGER-THAN-N-SECONDS 11
      :ONLY-IF-IT-WOULD-RECLAIM-FUNCTION-SPACE T
      :ONLY-IF-MACLISP-STYLE-GCTWA-IS-SUPPORTED T
      ...)
... but I just don't think that something as blunt as a single function is going
to cut it.

Also, I think the whole point of GC is to optimize those features of the 
implementation which are beyond the scope of the CL spec, and I think that's a
good hint that we're going in the wrong direction by suggesting that we can
do such optimization with a blindfold on.

By the way, it seems to me that the purpose of the GC is to be invisible to
the user. Lisp is really organized around the idea that you don't think about 
memory management. If we can't even write reasonable, portable programs without
having to call GC explicitly, I think there may be something more fundamentally 
wrong with the language.

I'd probably suggest we introduce RECLAIM in CL before we introduce GC just
because it is at least possible to define in a portable way -- albeit horribly
dangerous, as anyone who's tried to use it in serious code has no doubt figured
out.