Subject: Re: Allocating on the stack and *only* on the stack
From: Erik Naggum <>
Date: 12 Dec 2000 16:25:35 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Tim Bradshaw <>
| Think of locks or
| resources on a remote machine, -- you *really* don't want to leave it
| up to the GC to free that kind of thing.

  I think it is important to realize that GC doesn't _free_ memory or
  objects.  A transitive, active verb here implies something that exists
  and that something is done to it.  Not so.  Unreferenced memory does
  not exist as far as (access to) objects is concerned.  The reason it
  is not usable for new allocations is that even the allocator doesn't
  know it exists.  GC makes such unreferenced memory usable, again, but
  at this point, we have an essentially uninitialized resource that
  cannot possibly keep track of what it was last used for.  Let's call
  this _abandoned_ objects and memory.

  This is in sharp contrast to "freeing" an object, an active operation
  on an object that still exists qua object.  When the free function
  puts a chunk of bytes back on the free list used by malloc, the memory
  never _ceases_ to be referenced.  It is in fact an _error_ for memory
  to be abandoned in such a system!  (It's 3:30 AM.  Do you know where
  your memory is?  My God, it must be hard to live in the C++ mindset,
  parenting _memory_ as if it were a scarce resource.  Sheesh!)

  I supposed that if you think only in terms of referenced memory and
  that memory always has a structure, it will be very ahrd to switch to
  think in terms of unreferenced memory and allowing yourself to let go
  of memory, since that used to be a source of serious problems and
  outright pain and suffering during development.  If you aren't aware
  of what hurts, you're likely to fear something else that appears to
  coincide with it.  (Such as people who can't be bothered to figure out
  the difference between posting to comp.lang.lisp and being stupid.)

| And Lisp people *also* confuse it with storage management and since GC
| does largely solve that problem assume that these other problems must
| be solved too.

  Let's find a way to help Lisp people overcome that confusion, since GC
  doesn't solve any other problem than how to reclaim abandoned memory.
  If something else happens at GC time, I think it needs to be spelled
  out that there is a (very significant) convenience factor in doing it
  at that time, not an intrinsic relationship between the reclamation of
  abandoned memory and the more complex ways through which objects may
  be discovered to have been abandoned after all the next time around.

  Example: You don't have to reclaim abandoned memory to find that some
  object has no other references than that from the finalization list,
  it's just massively more efficient to mark the old objects you copy in
  a copying garbage collector so you can walk over the list of objects
  to finalize and see if anyone of them are still unmarked, at which
  point you call the finalization code associated with those objects.

  "When you are having a bad day and it seems like everybody is trying
   to piss you off, remember that it takes 42 muscles to produce a
   frown, but only 4 muscles to work the trigger of a good sniper rifle."
								-- Unknown