←back to thread

Fil's Unbelievable Garbage Collector

(fil-c.org)
597 points pizlonator | 3 comments | 05 Sep 25 00:55 UTC | HN request time: 0.018s | source
Show context
kragen ◴[05 Sep 25 04:55 UTC] No.45135095[source]▶
Hmm, Fil-C seems potentially really important; there's a lot of software that only exists in the form of C code which it's important to preserve access to, even if the tradeoffs made by conventional C compilers (accepting large risks of security problems in exchange for a small improvement in single-core performance) have largely become obsolete.

The list of supported software is astounding: CPython, SQLite, OpenSSH, ICU, CMake, Perl5, and Bash, for example. There are a lot of things in that list that nobody is likely to ever rewrite in Rust.

I wonder if it's feasible to use Fil-C to do multitasking between mutually untrusted processes on a computer without an MMU? They're making all the right noises about capability security and nonblocking synchronization and whatnot.

Does anyone have experience using it in practice? I see that https://news.ycombinator.com/item?id=45134852 reports a 4× slowdown or better.

The name is hilarious. Feelthay! Feelthay!

replies(8): >>45135151 #>>45135324 #>>45135967 #>>45137459 #>>45139406 #>>45139586 #>>45139998 #>>45140957 #
pizlonator ◴[05 Sep 25 05:05 UTC] No.45135151[source]▶
> I wonder if it's feasible to use Fil-C to do multitasking between mutually untrusted processes on a computer without an MMU?

You could. That said, FUGC’s guts rely on OS features that in turn rely on an MMU.

But you could make a version of FUGC that has no such dependency.

As for perf - 4x is the worst case and that number is out there because I reported it. And I report worst case perf because that’s how obsessive I am about realistically measuring, and then fanatically resolving, perf issues

Fact is, I can live on the Fil-C versions of a lot of my favorite software and not tell the difference

replies(5): >>45135179 #>>45135182 #>>45135319 #>>45136221 #>>45136740 #
willvarfar ◴[05 Sep 25 05:44 UTC] No.45135319[source]▶
When you run the Fil-C versions of your favourite software, does it have a sanitizer mode that reports bugs like missing free() etc? And have you found any bugs this way?
replies(1): >>45135331 #
pizlonator ◴[05 Sep 25 05:46 UTC] No.45135331[source]▶
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.

replies(2): >>45135508 #>>45135860 #
writebetterc ◴[05 Sep 25 07:22 UTC] No.45135860[source]▶
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.
replies(2): >>45135872 #>>45136163 #
kragen ◴[05 Sep 25 07:25 UTC] No.45135872[source]▶
Really? How does a non-moving GC make dead objects available for reallocation without visiting them?
replies(2): >>45136460 #>>45136527 #
thomasmg ◴[05 Sep 25 09:07 UTC] No.45136527[source]▶
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.

replies(1): >>45136617 #
1. kragen ◴[05 Sep 25 09:24 UTC] No.45136617[source]▶
That works if you use a copying garbage collector, but not a non-moving collector like FUGC.
replies(1): >>45136835 #
2. thomasmg ◴[05 Sep 25 10:00 UTC] No.45136835[source]▶
OK, I did not read the source code of the FUGC, but the article mentions "FUGC relies on a sweeping algorithm based on bitvector SIMD." So, assuming there is just one bit per block of memory, then there is no need to visit the memory of the dead objects in the sweep phase. The bit of the dead object is zero, and so that memory block is considered free and available for reallocation. There is no need to visit the free block.
replies(1): >>45137139 #
3. kragen ◴[05 Sep 25 10:47 UTC] No.45137139[source]▶
It's true that it doesn't dirty up your dcache, but it's "visiting" enough that it wouldn't "need a lot more special support if it wanted to report the dead objects," which is the context of the discussion here.