←back to thread

Fil's Unbelievable Garbage Collector

(fil-c.org)
597 points pizlonator | 5 comments | 05 Sep 25 00:55 UTC | HN request time: 0.206s | 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 #
1. tomp ◴[05 Sep 25 08:08 UTC] No.45136163[source]▶
A non-moving GC must visit dead objects.
replies(2): >>45137272 #>>45138453 #
2. writebetterc ◴[05 Sep 25 11:13 UTC] No.45137272[source]▶
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?

replies(2): >>45137576 #>>45138133 #
3. kragen ◴[05 Sep 25 12:04 UTC] No.45137576[source]▶
Yes, I agree. (This thread continued in https://news.ycombinator.com/item?id=45137286.)
4. tomp ◴[05 Sep 25 13:11 UTC] No.45138133[source]▶
You’re correct, I forgot about that optimisation!
5. pizlonator ◴[05 Sep 25 13:40 UTC] No.45138453[source]▶
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.