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

From: Galler (lzgaller at optonline.net)
Date: Fri Feb 15 20:45:09 EST 2013

Matthew and Ryan and Robby,


The issue regarding major collections occuring with no activity was due 
to the collect function executing in lru.rkt on a timer.  Now no 
activity equals no collections. Thanks Ryan.


Purpose of following is to attempt to predict application performance 
(and how changes will affect GC times)

As far as estimating memory size of application. The following thumbrule 
seems to work, and I'll look to obtain more data over time.

a) Take the initial size of the loaded executable with a clean-ish heap 
(i.e. run collect-garbage upon startup).

b) Subtract 32MB for the initial nursery page.

c) add this result back to (a) to obtain the projected peak memory size

d) major GC time: to calculate an expected time for GC seems to take 
[hardware-specific] k milliseconds per MB of _total memory used_ (not 
memory reclaimed, or heap memory)

e) minor GC time:  32MB times k ms/MB

so for example:

a) 182MB initial loaded size

b) 182MB - 32MB =  150MB

c) 182 + 150 = 332MB target peak memory size

on arbitrary machine, call  k  4ms/MB


d) 332 * 4 =  1328 ms for major cycle duration

e) 32 * 4 =  128 ms for minor cycle duration

So Next Question is: Is major GC time really proportional to total 
memory usage and not just heap size?

I confess ignorance, do bytecode systems allow for separation of code 
segment and heap segments?

Posted on the users mailing list.