verwaest

6 ms·

1. 1.▲
   by verwaest 3y ago

   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 a
2. 2.▲
   by verwaest 5y ago

   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 t
3. 3.▲
   by verwaest 7y ago

   Also we'll probably lose some cache benefits from compression due to larger alignment.
4. 4.▲
   by verwaest 7y ago

   Decompression isn't the problem, compression is. Compression is just a mov. Now we need additional shifts.
5. 5.▲
   by verwaest 7y ago

   +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.
6. 6.▲
   by verwaest 7y ago

   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
7. 7.▲
   by verwaest 7y ago

   Sounds like a fun project in the context of a moving GC :)
8. 8.▲
   by verwaest 7y ago

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