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

Matt, Ryan

Thanks very much for the answers, let me think about.

I'm looking at the issue Ryan brings up with module references to 
lru.rkt, which surprised me.

R./
Zack

On Fri, Feb 15, 2013 at 2:39 PM, Matthew Flatt wrote:

> 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.