[racket] Garbage collection in Racket

On Mon, Jul 23, 2012 at 06:19:02PM +0200, Rüdiger Asche wrote:
> >
> >For complete precision: I meant "may" in the sense of "P |= memory
> >is useful" as opposed to "P |- memory is useful" -- i.e., just
> >because a program may not need a chunk of memory for the remainder
> >of the computation does not mean it is provably so. In this
> >spirit, the word "conservative" is a bit misleading. All GCs are
> >conservative in the sense of |= vs |-. Hans's choice of
> >"conservative" is entirely wrt to the context in which the GC
> >operates. In his case, the roots of the graph traversal are
> >conservative approximations because they aren't really known. His
> >GC "guesses" the roots and to make sure that the GC doesn't
> >destroy the program's useful memory, it has to over-guess -- be
> >conservative.
> >
> 
> As an embedded developer, I'm sort unhappy about this
> conservativeness (one of the things we're after in embedded is at
> least a rough approximation to real time, and unpredictable and
> possibly very lengthy system induced "hiccups" in responsiveness are
> one of the things we really really loathe). I frequently daydream
> about an application supported garbage collection scheme along the
> spirit of "your mother will clean up your room if you don't, but if
> you do it yourself, she won't that easily get into her moods
> anymore." Has there been any thought along those lines - for example
> some kind of primitive that flags a previously constructed item as
> unused so a garbage collector can kick in more precisely or pick
> that structure as a preferred candidate for collection? I understand
> that not doing it right on the application side may cause some very
> nasty errors (which is probably one of the reasons why garbage
> collectors prefer to work unsupervised), but working with limited
> resources almost inevitably calls for compromises, so I'd much
> rather have an abandon primitive and buy a better approximation of
> real time (along with some more debugging and error potential) for
> it than not be able to use a system like Scheme at all...

There was a language long ago, predating Lisp, that used reference 
counting for memory management.  I forget what it was called.  Could it 
have been IPL-V?  It was a list processing language in which the program 
consisted of assembly-like instructions to perform actions on the list 
structure.  Of course these instructinos were themselves in list 
storage.

Reference counting might do what you want, if when you know memory is no 
longer useful you delete all pointers to it.  And it could be safe.  It 
will take more time and space, but it could be implemented so as to free 
parge trees gradually, avoiding long delays.

It would probably mean reimplementing whatever Scheme you use.

There could still be the backup of full garbage collection to clean up 
stuff with lots of cycles.

-- hendrik
 
> 
> Thanks!
> 
> 
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users