pizlonator

Good point.

Oracle stock is up today.

Refreshing to see this.

The pricing ($.68 in/$.07 cached/$2.09 out) makes it much cheaper than Kimi K3, GLM 5.3, and Meta Muse Spark 1.3. That's great!

But also much more expensive than GLM 5.3-flash and Spark 1.3 Contributor (the Meta-takes-your-data pricing of Spark 1.3).

So, I think it would have to be significantly better than GLM 5.3-flash to be worth it. GLM 5.3-flash is already very good.

The classic on the fly GC algorithm is DLG, hilariously published in two papers, because the first one had a bug. Here's the second paper: https://caml.inria.fr/pub/papers/doligez_gonthier-gc-popl94....

It's a well known algorithm. Folks who do GCs for a living know about it. The folks who work on Go are surely aware of it. I'm assuming that they do not use it for a good reason, hence my question!

Fil-C's GC (Fil's Unbelievable Garbage Collector) uses an alternative on-the-fly algorithm, which I call Phil's Concurrent Marking.

I've documented it here: https://fil-c.org/fugc

Here's the source: https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/l...

Phil's Concurrent Marking differs from DLG in that it only requires a Djikstra barrier and uses a permagrey stack (something that Go used to do).

However, FUGC does clever things for coroutines (as in ucontexts, which Fil-C supports) - they are not permagrey; they only become grey if they execute. That's relevant to Go because Go moved away from permagrey stacks because of coroutine scan overheads, which the FUGC coroutine strategy might avoid.

But even if Go could not go back to permagrey, then the answer would be to use DLG, which would involve using the combined Yuasa+Dijstra barrier, which Go uses today anyway

Is there a reason why Go isn’t using on the fly GC, where there’s no STW at all?

Yes, Fil-C delivers almost all of its safety guarantees at runtime, because from a security standpoint, that's good enough.

> But we literally do already have WebP for WUFFS.

This comes down to how strong your claim is, and what point you're trying to make.

If you're saying that compiling codecs in Fil-C is not a good use of Fil-C in general, then that's wrong, because not all codecs have a WUFFS version.

If you're saying that compiling WebP with Fil-C is not a good use of Fil-C because there's a WUFFS version, then that's also wrong, because I can't use the WUFFS version in a fully memory-safe web browser, since WUFFS doesn't support Fil-ABI and nobody has written a browser where the whole transitive closure of everything that the browser uses is WUFFS or some other safe language.

On the other hand, that is possible with Fil-C. (I'm posting this comment using a memory safe browser built with Fil-C, which has WebP built with Fil-C as well as everything else down to the libc/libc++ layer built with Fil-C.)

> double-free

Double-frees are deterministic panics in Fil-C. So yeah, Fil-C catches that, and any other memroy safety violation that could be used to achieve weird execution

> any real cases where you can afford Fil-C but you can’t afford WUFFS

Anytime you already have the C or C++ code but not the WUFFS.

The main use case for the Fil-C build of webp is my memory safe web browser, which is built entirely using Fil-C (including all dependencies).

> WUFFS codec is obviously going to be a lot faster than Fil-C for similar development effort

For greater development effort. Fil-C is just C, so WUFFS is only comparable effort if that’s the only version of the codec you ever write, and in the unlikely case you are as productive in WUFFS as you would have been in C.

> it will catch a lot more than Fil-C

Like what?

Fil-C catches not just the bugs in your codec but any transitive misuse of it from other C or C++ code. So, while you might be able to pick out things Rust or WUFFS catch that Fil-C doesn’t, I can easily pick out things that Fil-C catches that nothing else can.

webp builds with fil-C just fine if you want actual memory safety.

This is great but it’s got caveats:

- assembly code. They may have been careful but it’s an escape hatch

- if it has basically any dependencies then those are likely to transitively pull in more unsafe code

His “Lost Interview” with Steve is incredible.

Listening to Steve talk about the benefits of object oriented programming is something else

> I’m not sure if you were getting at this by mentioning the ABI specifically

Fil-C dynamically links its runtime, and it's a goal to support having different runtime versions link against code compiled by different versions of the compiler, within the same ABI epoch.

Hence, the current thing where the compiler computes the allocator bucket means that the shape of allocator buckets in the thread object is part of the ABI.

> In the specialized functions, these conditionals become constant and lots of code falls away

I see. That's a key difference from Fil-C.

Fil-C's GC only specializes on size in the sense that you end up in a different allocator bucket.

> we definitely see an improvement with static calls vs computing the size class in the runtime

I don't doubt that you do.

I just find it interesting that I don't.

Not sure what the difference is

Not sure that protobuf change is the same thing

But you might be right on your overall point: on my big x86 CPU, it doesn't matter, but it might matter on some tiny arm thingy

Super interesting!

Fil-C's GC has basically always had size-specialized allocation and I've done some experiments with this so I have my own data.

As the post says, there are two potential benefits:

- Faster memory clearing when the compiler knows the size. In Fil-C, I leverage that by having LLVM emit a memset inline, so it often ends up being some SIMD crap.

- Faster size class computation.

Interestingly, the faster size class computation isn't really faster in practice. I implemented it and that's how the ABI works today, but I'm likely to move the size class computation into the runtime to simply the ABI, since repeated experiments show that there are no savings to be had there. It's super surprising, but the numbers don't lie.

Anyway, cool to see other fast non-moving GCs also finding the same sweet spot as me.

(Posted from WebKit built with Fil-C so for extra meta, I'm using the GC I describe to write this post)

This is neat.

But the benchmarks are tiny, and it’s likely that Goose was tuned on them.

So, I think I would read this as: Goose has competitive performance to C and Rust and I’ll take them at their word that it’s as memory safe as Rust

The wild thing about locks in particular is that microbenchmarks will cause you to make „optimizations” that are the opposite of what benefits real world workloads.

Super dangerous to benchmark lock performance using microbenchmarks. If you have a tiny benchmark, then you're putting the CPU and memory into a very specific and unusual state (everything is quiet other than the lock itself).

The real world story for locks is usually that you're not rage-contending 100% of the time, but that you have some contention combined with CPUs doing some real work and some real memory accesses.

What I've found is that in those more real scenarios, the locks that perform best in microbenchmarks fall apart compared to completely different and unexpected algorithms.

> easy to be safer

It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.

How would memory safety have not made a difference?

I'll port Epiphany eventually.

WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS object.

On the other hand, Chromium's JS engine (V8) does a bunch of crazy stuff with pointer encoding, so the best you could do there is probably a single arena for the whole JS heap.

Also, JavaScriptCore has a well-supported mode that involves not only zero JIT but a fully portable C++ interpreter. Not sure V8 has that.

Nah

It's damn near impossible to verify that the JIT is correct.

But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law.

(V8's heap sandbox is an example of this; a sarcastic JIT would be an arguably stronger example of this.)

lol yeah

Pls file bugs if you encounter issues.

Also, fair warning, it's hella slow right now on JS-heavy websites (like X). It barely works.

But we can fix that with some effort, I think

Yes

I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)

VM

https://fil-c.org/pizlix

Then build WebKit using do_cmake_yolo_simpler.sh in projects/webkitgtk-2.44.3

It's still pretty rough, but works more than well enough to post on HN. My regression test is to post on X. That works too

Yeah

There's a risk that someone had been sitting on a sandbox escape that assumed having RCE inside the sandbox first, and so they'd been waiting for an RCE exactly like this one.

Those folks would not be disclosing their sandbox escape unless they were good guys.

(Posted with a memory safe WebKit, Fil-C FTW)

I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs.

That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it.

(Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.)

Sounds wild.

(Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)

This doesnt seems to be meaningfully different from Rust.

> does not require tracing garbage collection

Just call it garbage collection.

(Applies in two ways: if you think that garbage collection subsumes reference counting then this language doesn’t require garbage collection in the sense that it also doesn’t require reference counting; if you think that garbage collection does not subsume reference counting then there’s no point in saying three words when you can say two.)

That is a great feature

But it’s strictly less safe than either Fil-C or Rust since it only protects bounds

Correct