3 ms·

If we're going to go for 128- why not just go for 256-? that way we won't have to do this again for a while. or better yet, design a new abstraction for not ha

• kmeisthax 4y ago
  The problem with variable-sized pointers is that... 1. Any abstraction you could make will have worse performance than a fixed-size machine pointer 2. In order to support any kind of variably-sized type you need machine pointers to begin with, and those will always be fixed-size because variable size is even harder to support in hardware than native code And furthermore going straight to 256 has its own problems. Each time you double the pointer size you also significantly increase the size of structures with a lot of pointers. V8 notably uses "pointer compression" - i.e. using 32-bit offsets instead of 64-bit pointers, because it never needs >4GB of JavaScript objects at once and JS objects are very pointer-ridden. There's two forces at play here: pointers need to be small enough to embed in any data structure and large enough to address the entire working set of the program. Larger pointers are not inherently better[0], and neither are smaller pointers. It's a balancing act. [0] ASLR, PAC, and CHERI are exceptions, as mentioned in the original article.