[gambit-list] Help With Memory

Christian Jaeger christian at pflanze.mine.nu
Wed Sep 24 11:19:21 EDT 2008


I don't have the time to dig into your code. Just to make sure:

- be sure to compile the program; the Gambit interpreter does not 
analyze the lifetime of lexical bindings, and thus retains memory longer 
than necessary, and thus possibly longer than you anticipated. So make 
sure you compile the program before concluding that it has a memory problem.

- if there is in fact a memory problem with the compiled program, then 
run it in the interpreter ;-). Or at least partially (you could compile 
the parts of the programs you don't want to analyze at the moment). 
Because then you can easily step through it and find out what happens. 
(For debugging, also make sure you know how to use 
|generate-proper-tail-calls|.)

- find out what the reason of the out of memory situation could be: is 
(a) your problem maybe just asking for more memory than you've got?, or 
(a2) your problem doesn't necessarily ask for more memory than you've 
got in principle, but the way you're evaluating it (e.g. calculate to 
eagerly) requires too much memory at once, or (b) you've got an error in 
the program which leads to an infinite loop allocating memory, or (c) 
your program is holding on to memory that it doesn't need anymore?

For (c) check your assumptions about the lifetime of memory: 
particularly, be aware that structs (as defined using define-structure 
or define-type), or in fact any data structure like cons cells and 
vectors, will hold on to every location in them, even to those you'll 
never use again (this is unlike lexical bindings, which, as I've told 
above, will be analyzed by the compiler and only live as long as the 
program will possibly refer to them). If in doubt, copy the relevant 
data to new datastructures (or, if you want to go imperative, delete 
places in the structure by setting them to #f or (void) or whatever).

For (a2) using delay and force can help; but check my post at 
https://webmail.iro.umontreal.ca/pipermail/gambit-list/2007-May/001435.html, 
i.e. the current promises actually do retain memory longer than they 
have to ;), this is an example for which my hint above for problem (c) 
applies. So you might actually want to use the implementation of delay 
and force given in that mail.

Note that when heeding these precautions I could never get Gambit to 
leak memory in compiled programs. (So my expectation is that (unless 
some other implementation implement structures or vectors as dissectable 
entities, which I doubt) you won't get better behaviour by porting to 
other implementations.)

Christian.




More information about the Gambit-list mailing list