Re: Opportunistic GC

[Pip Cet <pipcet@gmail.com>]

On Mon, Mar 8, 2021 at 3:46 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> Ah, so not really an easy change after all.
> >
> > For conses, it's easy. Instead of keeping the mark bits in the cons
> > block, we keep a pointer to the mark bits in the cons block, and
> > allocate the mark bits separately and (hopefully) on a different page.
>
> What you mean is that it's easy because the markbits are already
> separate from the cons objects (same for floats).  We could also just
> increase the size of the cons blocks such that their markbits area takes
> up a whole page.  That means cons blocks of about (* 16B/cons 8b/B) =>
> 128 pages => 512KB.

I don't understand the benefits of doing that. The disadvantages would
be very significant: we can't free a cons block until all its conses
have been freed, and that's drastically more likely if we increase the
cons block size by a factor of 128.

Note that 4KB pages are no longer all there is. I hear even VAX uses a
different page size ;-)

> >> And how do you propose to keep the mark bits separately and still
> >> maintain coherency between the object and its bits?
> > Just as we do for pdumper, which already does this.  In fact, I'm
> > pretty sure it was Daniel who said a while ago that he wants to extend
> > that to all GCable objects, not just those that live in the pdmp.

> Yes, it's a good idea to do that in general.

I agree it's a good idea to use the same approach for pdumped objects
and regular old objects, but I don't think the current pdumper
approach extends to dynamically-allocated objects, and I'd rather
avoid searching a btree for each mark bit. That means pdumper has to
be modified to keep its objects in blocks, and those blocks need a
pointer to their mark bits, but we don't want to fault them in just to
set the mark bits pointer, so we'd need a relative pointer, and then
things start getting complicated...

Pip