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)

https://github.com/protocolbuffers/protobuf/commit/50f9ac3ba...

On a sufficiently anemic CPU doing enough fast allocation you can get measurable improvements from that kind of thing, but for a superscalar CPU and a general purpose allocator I agree you'd be hard pressed.