[rucksack-devel] thoughts on deferring GC

[Arthur Lemmens]

Cyrus Harmon wrote:

> 1. Do we want an interface for doing GC at some point?

Yes, I think so.  We'd probably want at least the following:

- turn it off completely

- run one complete round of GC

- set the ratio between amount of work / amount of allocated

- (maybe) specify some kind of maximum heap size.  If specified,
   the heap may never grow beyond this size.

> How do we go about recovering the additional space from
> the transactions with :gc-inhibit t?

If you turn GC on afterwards, sooner or later it will recover the
additional space.  Probably ;-)

> 2. Do we ever reclaim the disk space, besides just freeing the blocks
> up for later use?

Not in this version of the GC: it's a mark and sweep collector that
doesn't compact the heap.  I've written most of a copying collector,
but I haven't committed that to CVS yet because it isn't finished.

But in the long run, I think Rucksack should move to a copying GC.
It's safer, simpler and it compacts the heap as part of the copying
process.

> 3. The GC code seems to give SBCL fits. I'm a bit concerned about the
> fake_foreign_call falling through stuff, which is basically a SIGILL
> or SIGBUS in SBCL. These occasionally happen under rare circumstances
> with SBCL, but GC, both during the transaction, and when done after
> the fact, seem to greatly increase the likelihood of this happening.
> Either we're doing something funky or we're tickling an SBCL bug
> that's causing it to go haywire.

Hmm.  If you finish the copying GC (should be relatively simple, I
think that all the basic work is already done), you could try that
one instead.  I can send you the code if you're interested.

Arthur