Some folks get religious about C versus C++. I love both languages. Favorite thing about C: transparency - every expression has a clear meaning. Favorite thing about C++: abstraction - you can say so much with so few bytes. What's important is they're both better than Rust.
This was a fun project to watch. And what a gloriously huge patch. Our bet that certain interpreter speed optimizations are inconsequential to JIT perf and so only cost memory paid off.
Memory-safe C++! Thanks to Fil-C now being able to compile libcxxabi and libcxx and being able to handle the (pizlonated version of the) Itanium C++ ABI, including member function ptrs, vtables with virtual base classes, etc.
Fil-C is now only 10x slower than C on average. Best case, XZ utils decompress, is only 3x slower.
Recall I started at 200x slower. And I'm not done optimizing. This is only the beginning of my rampage.
Fil-C wouldn't be possible without the awesomeness of the clang/llvm codebase. I love how anytime I have a complex question about how C or C++ semantics are handled, the answer is in the code, clear as day, written in a wonderful hacker-friendly style.
This doesn’t get said enough: the ES spec is really great. The best language spec I’ve had the pleasure of implementing to. So unambiguous, even when that wasn’t the easiest thing to do.
Spectre means that you now need next-level talent to write a secure language VM. It’s game changing. It’s the most exciting thing I have seen in my life.
Just made Fil-C ~10x faster. Less than a week of work (started on Saturday). Just two optimizations got me there, and there's still a ton of obvious stuff to do.
My view: I prefer to publish blogs these days because I get *more* peer review than if I submitted for publication. I get reviews faster, from more people, and those reviews lead to more constructive conversations. That's how peer review should be.
WebKit IsoHeap = C++ template program that generates a first-fit amortized O(1) malloc with atomicless fast paths specialized for a type (size + alignment), which guarantees that once a virtual address gets used for a type, it never gets used for any other type.
Fil’s Unbelievable C Compiler now runs an inlining pipeline before the program gets pizlonated.
This makes Fil-C ~40% faster than before on the PizBench benchmark suite geomean.
On stepanov_container, Fil-C++ is now only ~2x slower than Yolo-C++.
Great news everyone. My compiler can compile hello.cpp with exceptions enabled without crashing!
(Don't ask me if it actually runs. I'm too scared to find out. I'll save that for another day.)
This is what UAF looks like with FUGC. This is guaranteed. It'll always trap. No tagging. No probabilities. No shenanigans. No way around it. Your program just gets fugced.
@NovallSwift
My philosophy: If you make a mistake in production just remind yourself how cool it is that your code is in production and then skip the part where you fault/blame.
I can now compile *and* run hello.cpp with exceptions enabled. Note that this means I can compile and run libc++ and libc++abi with exceptions enabled.
Now.... I just need to see what happens when I actually throw an exception. 🙈😱
My concurrent GC is so awesome right now that I get concurrent crashes in the main thread and the GC thread, and hilariously, neither threads' crash is caused by the third bug, where the GC deletes the entire heap (we don't get far enough to crash from that UAF).
VICTORY!!!
Fun fact: JavaScriptCore’s concurrent/parallel JIT and concurrent/parallel GC use “cowboy races” liberally. They would not work in TSAN, Rust, clang thread safety analysis or anything that ties types/fields to mutexes or uses the classic definition of races.
Working on adding “zero cost” C++ exception handling, libunwind, and setjmp/longjmp to Fil-C. Longjmp from signal handlers will be especially interesting. Wish me luck!
We are now live with Verse runtime error telemetry! See bottom of for more info. Or, just go to , click the Verse tab, and if your project has errors in live, they will show up there. Happy debugging!
Fil-C on FreeBSD/X86_64 is now at parity with Darwin/AArch64. Here's a memory-safe ssh client on my Mac connecting to a memory-safe sshd server on my FreeBSD ec2 instance.
My favorite thing about POSIX C programming is how many headers you have to include to do things.
Makes me feel so accomplished and professional for knowing all their stupid names.
Am I crazy?
If you have an Apple Silicon Mac and you want to try memory-safe Fil-C and Fil-C++, here's a binary release. Just untar and run ./setup.sh. LMK if you run into problems, but no guarantees since nobody is paying me to work on this.
I just wrote the world's shittiest liveness analysis an I'm so proud of myself.
(Yes, doing an accurate GC means writing a liveness analysis over llvm IR. No, llvm IR doesn't want you to do that. But I don't care what llvm thinks.)
@jarredsumner
My view of why JSC has a cheaper and better embedding interface is that it's all about JSC's use of nonmoving, conservative-on-the-stack GC. That was a conscious bet on my part >10 years ago and I'm happy to see that it paid off.
My abstract interpreter has won the practice round. In a program like `int foo(int* x) { return x[0]+x[1]+x[2]+x[3] }`, it schedules only one combined check for all four accesses.
Lots of work remains before it can handle anything more complex...
This jpeg was encoded using memory-safe IJG libjpeg-6b. It only took a one line change to get it to build and run with Fil-C (ALIGN_TYPE in jmemmgr.c).
I've got Fil-C on FreeBSD/x86_64 working well enough to print hello, but so far with out a stdlib (I haven't gotten a libc working yet, just libpizlo/libfilc_mincrt).
OK, Fil-C is now a Linux/X86_64 project. Darwin and FreeBSD support is dropped. This allows me to use the Musl Sando architecture: same version of musl below and above libpizlo, allowing much cleaner syscall support. This will let me support a lot more stuff than before.
Achievement unlocked: I taught Molly enough about programming that she's now able to understand what kind of programming I do (and she was curious enough to ask).
@thingskatedid
It’s the state of the art of probabilistic GCs. Because there is some probability that it will work for some program, and that program will experience unbelievably short GC pauses with this technology.
Cool story: process shared pthread primitives work great in Fil-C! And it is in fact totally memory safe (the shared memory has int type, which is enough for pshared mutex/cond since they use int futexes for coordination).
@agent_cooper
I think it's actually a super popular opinion held by a folks who are too busy building real systems instead of bitching on twitter/hackernews. I ❤️ C.