verwaest

Actually this concern is exactly why we built Maglev: A very fast JIT that can generate decent enough code very early so it can help even if you're not running tight benchmarks. In fact, the JIT by itself isn't particularly good at the traditional benchmarks yet. It's just very fast, and the code is most often good enough for real browsing usecases.

I'm guessing that benchmark is so short-running that adding compile overhead doesn't result in code that manages to pay for the compile overhead. It's unlikely a huge problem on that short-running benchmark though. But fair to show the weak points as well as the strengths of Sparkplug.

Also we'll probably lose some cache benefits from compression due to larger alignment.

Decompression isn't the problem, compression is. Compression is just a mov. Now we need additional shifts.

+1. In fact even the JavaScript heap isn't limited to 4gb, just the space that pointers can point to. For example, we allocate large typed arrays outside of the V8 heap.

We're definitely interested in exploring this. Unfortunately it's likely a little slower than 4gb PC: Compression right now is basically a no-op, decompression simply being a single add instruction. And it'll fragment memory a little because of the alignment requirements. But surely worth it for where larger heaps are necessary.

Sounds like a fun project in the context of a moving GC :)

It does: pointers in the V8 heap all lie within the same 4gb region. But then again, Spectre also makes ASLR much less effective.