## Larceny Note #11: Experiences with the Conservative Collector

Lars T Hansen / November 23, 1998

## Experiences with the conservative collector

### Incremental mode

The conservative collector's incremental mode is not useful in Larceny (at least not under SunOS). The header file says the following about incremental mode:

    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 83 1998-11-25 14:12:22Z lth $
larceny@ccs.neu.edu