[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