[racket] Garbage collection in Racket

On Jul 23, 2012, at 12:09 AM, Neil Toronto wrote:

> On 07/22/2012 04:43 PM, Matthias Felleisen wrote:
>> 
>> On Jul 22, 2012, at 4:21 PM, Harry Spier wrote:
>> 
>>> 1) If [some memory is no longer being referred to], does that always ensure that doing a (collect-garbage) will reclaim the memory?
>> 
>> Garbage collection may retrieve all memory that can provably not affect the future of a program execution. Existing garbage collectors perceive all of memory as a graph and traverse it, starting from a set of roots (e.g., stack, registers). If they can reach a chunk of memory, the corresponding data stays available; otherwise, it is made available fir future allocations.
> 
> Harry: "may" is an important word. I wouldn't write a program whose correct operation depends on unreachable memory being reclaimed on the next collection cycle. (It's possible to write a program like that using finalizers, but you probably weren't planning to. :D) Many kinds of collectors don't guarantee it.
> 
> "Conservative" collectors can't even guarantee that any memory will ever be reclaimed, though on average they reclaim almost all of it.

[[ Side notes, most irrelevant to anybody's programming life: 

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. 

]]


> 
>>> 2) What triggers automatic garbage collection.
>> 
>> Any attempt to allocate memory that does not find enough available memory: cons, struct construction, lambda, etc.
> 
> Don't count on this, either. IIUC, it can be better for collection cycles to be triggered under different criteria. Racket's might change in the future.

[[ It is indeed true that GCs could be triggered more frequently than in the situations I described. Indeed, most implementations do so. But these points are the "conservative" points of GC events. ]]