Re: markbits out of cells. 1st attempt.

[Jim Blandy <jimb at savonarola dot red-bean dot com>]

> I wasn't thinking of CPU cache behavior.  The problem I want to solve
> is GUILE gc in combination with paging (Read: formatting large scores
> in LilyPond).  The current marking scheme has two major disadvantages:
> 
> 1. mark bits are written all over the heap (in a disorganized
> pattern), causing many pages to written during the mark phase.

Ah.  If a page is unmodified, a competent pager won't write it back to
the swap device, but will simply throw it away when it needs to bring
in something else.  So reducing the number of pages that get modified
is a win.

> 2. to check a mark bit, the part of the heap containing the cell has
> to be in core, causing many pages to be read (in a disorganized
> pattern.) - note: you don't need to know the contents of a cell if it
> is already marked.

Well, I've heard rumors that the vast majority of objects have only
one pointer to them, so if you're going to read the mark bit, you're
almost certainly going to read the object's contents as well.

It would be a service for someone to abuse `patch --ifdef' and produce
a single tree that has everyone's hacks, selectable with different -D
switches, and publish it somewhere so people could run their tests.

BTW, I don't think I was especially clever in writing that GC
benchmark.  While you folks are looking at the GC, you might also want
to make sure the test is doing something credible.