Comment by pizlonator
11 days ago
Well missing free is just swallowed by the GC - the leak gets fixed without any message.
I have found bugs in the software that I’ve ported, yeah.
11 days ago
Well missing free is just swallowed by the GC - the leak gets fixed without any message.
I have found bugs in the software that I’ve ported, yeah.
This is neat work. I noticed on your software page some patches you had to make to get those things to compile. Have you sent those upstream? Eg, I noticed a simple 1 line bash change for example.
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.
A non-moving GC must visit dead objects.
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.
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?
2 replies →
Really? How does a non-moving GC make dead objects available for reallocation without visiting them?
Why would it need to visit them? It just marks the address ranges as available in its internal bookkeeping (bitmaps etc).
12 replies →
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.
3 replies →