Hacker News Reader

Comment by slug | Hacker News Reader

Anyone has a good argument why NOT to use this for every non memory intensive application? I always thought that using 64bit pointers was a waste of memory when not needed and this x32 abi to me seems fantastic since it keeps the several advantages of newer 64bit cpus (more registers for example as mentioned in the article).

View on HN

Recently there was a HN thread [1] about the conservative garbage collection used in some 32bit VMs (the complaint started with Go), because the way their GC works is by scanning portions of process memory for 32 bit values that map to valid address space for that process. Those values are treated as pointers even if they're not pointers, so the data they point to is assumed to be used and is not garbage collected.

Architectures/ABIs with 64bit pointers have a much lower probability of arbitrary values mapping to active memory space for the process, so memory bloat caused by the conservative GC strategy is much more limited.

The x32 abi looks like it would suffer from this 32bit conservative garbage collection problem too. Short of changing the VM strategy, using 64 bit pointers is the only way to ensure that such VMs do not accumulate so much unused but not-garbage-collectable memory allocations.

[1] http://news.ycombinator.com/item?id=3814020

If an application is not memory intensive, why would you care if there is 'waste'? Personally I wish everyone would just move to 64 bit all the time.

An application that uses 64-bit pointers but doesn't need 64-bits of virtual address space is wasting physical memory because your pointers are twice as large. The application would waste physical memory pages and memory bus traffic just to store 64-bit pointers with lots of unused zero bits like 0x00000000ffffffff.

> If an application is not memory intensive, why would you care if there is 'waste'?

Performance. What other reason do you need? (Using cache more efficiently makes programs run faster).

Because there is a finite amount of cache at each level.

'not memory intensive' is an ambiguous term. he meant 'does not use a lot of memory, but may access what memory it does use quite a bit'. you meant 'does not access memory often, and performance thus does not depend much on memory access latency'.

Ten not memory intensive applications, combined, can easily be memory intensive.

address space randomization

(i can dig out a post of (afair) solar designer that goes into more detail, but i think this should be clear as is)

seems like a great idea. toolchain support may be an issue for a while, especially if you link against libraries with a different ABI. one thing to keep in mind is that the performance gain from e.g. more registers may not be as big as you'd think, since the hardware already plays lots of tricks to get around i386's limitations (e.g. register renaming) and likely extracts a good bit of the available ILP.

Actually main line kernel support is one of the last things that's been needed to get this going. gcc 4.7, and the latest glibc and binutils have had support for a little while. Now it'll still be a while before distros start supporting it as a first class citizen but the pieces are now there.

Reply on news.ycombinator.com