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

Matthew and Ryan and Robby,


MAJOR COLLECTIONS WITHOUT ACTIVITY


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.


BACKGROUND AND NEXT QUESTION


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

so

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?