The RAM savings look very high, but I guess a language with that header structure and a lot of small objects would have these properties. In some of the analysis that we did for CHERI, we typically found that under 20% of pages contained one or more pointers. A lot of memory ends up being big buffers, images, and other data that doesn’t contain pointers.
This is also a big part of the reason that x32 largely went away. One process using it may be smaller, but once you factor in the extra disk space and RAM from 32-bit and 64-bit shared libraries, you end up with a much less clear win. If everything used x32 then it would be a win probably but it turns out that JavaScript and some similar scripting languages like NaN boxing, so 32-bit isn’t a win. Similarly, lightweight SFI things (e.g. WebAssembly) work nicely if you can carve out a 4 GiB chunk of the address space and just truncate pointers to that size (optionally with a base offset). So you find that things like Node.js and web browsers want a 64-bit system.
The same thing happens with JVMs, where it’s nice to be able to map the heap in at least two places for generational GC. You also want to be able to have a large address range to put your Java objects in that doesn’t overlap anything else, so a 2 GiB userspace address space may limit you to something on the order of a 300 MiB heap. And the pointer size increase doesn’t matter for JVMs because 64-bit JVMs typically use a 32-bit integer to represent objects, which is an offset from the base of the heap right shifted by 3 or 4, so you can have a 64 GiB heap. And you can often put NIO buffers and large arrays in a separate heap region with only a small object header in the 64 GiB heap, which lets you actually scale to heaps that are a large fraction of a TiB, without any real pointer-size overhead.
I believe v8 (and consequently Node and browsers) doesn’t use NaN boxing, and instead puts doubles on the heap: https://v8.dev/blog/pointer-compression . Ironically it’s exactly to get the smaller pointer cost we’re chasing with x32!
The RAM savings look very high, but I guess a language with that header structure and a lot of small objects would have these properties. In some of the analysis that we did for CHERI, we typically found that under 20% of pages contained one or more pointers. A lot of memory ends up being big buffers, images, and other data that doesn’t contain pointers.
This is also a big part of the reason that x32 largely went away. One process using it may be smaller, but once you factor in the extra disk space and RAM from 32-bit and 64-bit shared libraries, you end up with a much less clear win. If everything used x32 then it would be a win probably but it turns out that JavaScript and some similar scripting languages like NaN boxing, so 32-bit isn’t a win. Similarly, lightweight SFI things (e.g. WebAssembly) work nicely if you can carve out a 4 GiB chunk of the address space and just truncate pointers to that size (optionally with a base offset). So you find that things like Node.js and web browsers want a 64-bit system.
The same thing happens with JVMs, where it’s nice to be able to map the heap in at least two places for generational GC. You also want to be able to have a large address range to put your Java objects in that doesn’t overlap anything else, so a 2 GiB userspace address space may limit you to something on the order of a 300 MiB heap. And the pointer size increase doesn’t matter for JVMs because 64-bit JVMs typically use a 32-bit integer to represent objects, which is an offset from the base of the heap right shifted by 3 or 4, so you can have a 64 GiB heap. And you can often put NIO buffers and large arrays in a separate heap region with only a small object header in the 64 GiB heap, which lets you actually scale to heaps that are a large fraction of a TiB, without any real pointer-size overhead.
score 1 · canonical
I believe v8 (and consequently Node and browsers) doesn’t use NaN boxing, and instead puts doubles on the heap: https://v8.dev/blog/pointer-compression . Ironically it’s exactly to get the smaller pointer cost we’re chasing with x32!
score 1 · canonical