Comment by writebetterc

5 months ago

To add on top of this: This is a tracing GC. It only ever visits the live data, not the dead data. In other words, it would need a lot more special support if it wanted to report the dead objects.

23 comments

writebetterc

Reply
tomp  5 months ago

A non-moving GC must visit dead objects.

  • pizlonator  5 months ago

    Not quite.

    FUGC used a bit vector SIMD sweep using a bit vector on the side so it doesn’t visit the dead objects at all in the sense that it doesn’t touch their contents. And it only visits them in the sense that a single instruction deals with many dead or alive objects at once.

  • writebetterc  5 months ago

    I forgot that this GC is non-moving (I'm not used to that assumption, and it was a bit of a quick comment).

    I do find the statement dubious still, do you mind clearing it up for me?

    Given a page { void* addr; size_t size; size_t alignment; BitMap used; } where used's size in bits is page.size / page.alignment, surely we only need to visit the used bitmap for marking a memory slot as free?

kragen  5 months ago

Really? How does a non-moving GC make dead objects available for reallocation without visiting them?

  • torginus  5 months ago

    Why would it need to visit them? It just marks the address ranges as available in its internal bookkeeping (bitmaps etc).

  • thomasmg  5 months ago

    If you want to use a standard malloc / free implementation (dlmalloc etc.) then dead object need to be known, yes.

    But the malloc library could be fully integrated into the GC mechanism. In this case, there is no need. That's probably much easier, and faster, because the malloc can be simplified to bumping a pointer.