[racket] Yet another garbage collection question: major GC cycles

At Fri, 15 Feb 2013 14:16:38 -0500 (EST), Galler wrote:
> When an application is compiled and run, the garbage collector in v5.3.2 
> appears to run through a number of minor collection cycles, then will 
> execute two sequential major cycles, in rapid succession.
> 
> [...]
> 
> 1) Why are two successive major cycles neccesary?

Finalizers run only during majors collections. Often, an object is
retained by the finalizer of some other object, and so the garbage
collector tends to schedule another major collection after a major
collection triggers finalizers (with the expectation that more
finalizers may run the next time around).

> 2) Why do major cycles occur in the absence of activity? Is there a 
> timer associated with major cycles?
>
> 3) Is there an optimization going on between amount of memory 
> consumption that triggers the first major cycle and Racket's estimate of 
> the RATE of memory consumption? (fast as. frequent vs. slow and 
> infrequent)

A minor collection is triggered when the nursery is full. The nursery
starts out at 1MB, and after each minor collection, it is resized to
half the total memory in use up to a maximum of 32MB.

A major collection is triggered when current memory use is twice the
use at the last major collection. Also, as noted above, when a
finalizer runs, the next collection is scheduled to be a major
collection. Finally, a major GC is also forced every 1000 minor
collections (just in case), but that trigger doesn't often fire.

If there's really nothing happening, then no collections should be
triggered. A collection is triggered only due to allocation.

> 4) is there any rate-related term in the GC algorithm?

I think "rate-related" means something to do with time, but the GC
doesn't pay attention to time. Everything is based on how much memory
is currently used versus how much was used in the past.

> 5) How does Racket determine how much memory to ask the operating system 
> to allocate to an executable?

Racket requests memory to size the nursery (as described above) and to
create non-nursery pages when moving data out of the nursery during a
collection. The GC release pages as they are evacuated by a major
collection.

Depending the OS and whether places are enabled, there's an extra layer
of allocation chunking between the GC and the OS, but that just changes
the granularity of requests.