[racket] Garbage collection in Racket

On Jul 23, 2012, at 12:19 PM, 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...


You seem to be asking for Pascal or C/C++. Then again, is it possible that "critical" regions of your program could be managed via finalizers and your own memory administration? Giving up even one iota of GC soundness, sounds like giving up all of memory soundness though it's possible I am overlooking something.