verwaest
No user record in our sample, but verwaest has activity below (stories or comments). Likely we have partial data — the full bulk-load will fill profiles in.
No user record in our sample, but verwaest has activity below (stories or comments). Likely we have partial data — the full bulk-load will fill profiles in.
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…
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…
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…
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.