Larceny Note #11: Experiences with the Conservative Collector
Lars T Hansen / November 23, 1998
Experiences with the conservative collector
The conservative collector's incremental mode is not useful in Larceny
(at least not under SunOS). The header file says the following about
Not advisable unless dirty bits are available or most heap objects are
pointerfree (atomic) or immutable.
This is evidently the case on the Sparc -- the system thrashes endlessly
in memory signal handling during initialization; I have yet to even get
to the REPL prompt. I thought it might help to put the Scheme stack in
the C stack (which the system would presumably not write protect) but a
quick experiment did not give any observable improvement (it still
hadn't made it to the REPL prompt by the time I got bored.)
It would be interesting to revisit this issue under other operating systems.
Atomic and nonatomic objects
Running some benchmarks I observed problems with excessive storage
leakage. This leakage was reduced to a reasonable level by making sure
that all atomic (non-pointer containing) objects were allocated as such.
It appeared to be particularly important for floating-point data. There
are now two allocation entry points in the system: mem_alloc
and mem_alloc_bv, the latter allocates atomic data.
$Id: note11-bdw.html,v 1.1 1998/11/25 14:12:22 lth Exp $