Re: Opportunistic GC

[Stefan Monnier]

>> 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.

I'm not specifically arguing for it, actually.  Just pointing out that
there's fair bit of design space here.  I think we'd generally prefer to
avoid an extra level of indirection (the marking phase tends to "kill"
the cache and suffer from memory latency), so if we can compute the
address of the markbit directly from the object address, it's better.

> 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

Fully agreed.

> by a factor of 128.

[ IIRC the cons blocks are currently 16KB, so it would increase it by
  a slightly smaller factor.  Not that it matters, tho.  ]

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

Yes, we're *finally* slowly moving to slightly larger pages.

>> > 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,

Indeed.

> 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

Not just pdumper.  In the GC, the most important objects AFAIK are
strings and vector(like)s.  Vectors used to be handled fairly
inefficiently, but their importance has grown, so it's worth trying to
handle them very efficiently: there's even silver lining in that it
would allow us to treat more of the other types as vectors
(e.g. strings) and thus simplify the code.

E.g. It'd be worthwhile improving our vector allocation so they get
allocated in blocks of vectors of the same size.