Could the 64 bits CLR use compressed pointers?

Question

I've read a bit about compressed object pointers in some 64 bits Java VM implementations. As I understood it, the principle is storing a reference as a relative 32 bits address offset from one object to another instead of a full 64 bits pointer, to gain memory.

I believe that this kind of optimization is not currently applied to the .NET CLR. At least I couldn't find anything about it. Could it be potentially applied to it or would that be an impossible/useless/performance-degrading optimization because of how the CLR internally works?

Incontinent

Pretty pointless in .NET, just set the platform target to x86. The only point of running in 64-bit mode is to get past the 2 gigabyte virtual memory limit. Using compressed pointers utterly defeats that point. – Renown

I disagree. There are ways of doing compressed pointers that allow up to 32gb (or more) of memory, so there is value. As is the value in the performance wins. (of course, this is all hypothetical in CLR today.) – Waves

@HansPassant I believe you are misunderstanding the way compressed pointers work. By assuming pointers are aligned on 8-byte boundaries, the addresses can by right-shifted by 3 bits allowing an application to use 32-bit pointers to reference locations in up to 32 GB of process space. The CLR could leverage compressed pointers for object references, but raw pointers and references to array elements in primitive arrays would require full pointers. This situation seems like it could be implemented in the runtime. – Dzoba

Certainly it'll improve performance in some cases. For example look at the benchmarks for x32 ABI you'll see some increase in performance due to smaller pointer which might result in less cache miss. The more pointer usage in the program the more RAM is saved and more performance is gained – Neurotic

Answer 1

Though I'm not sure if you can do such a thing in .NET, a 64 bit machine generally has an abundant amount of memory (generally 4 or 8G), so saving a few 4 bytes won't have much effect. I would class it as "not very useful".

A quick Google hasn't shown me any signs of .NET being able to support (or even any interest in pointer compression/ORA).

Wharve

I disagree. While there may not be a 64 bit CLR, there would be value in compressed object pointers if they were to build one. 8 extra registers in 64 bit mode and better cache efficiency are the main reasons. – Waves

To highlight "better cache efficiency": L2 cache is a few megabytes, and stuff outside the cache takes ~100 cycles to access. – Examinee

-1: I have seen real-world application use 40% less memory by leveraging the compressed object representation. When you're talking about an application that uses 20 GB of memory in "full" 64-bit mode running on a system with 16 GB of physical ram, the performance gains are very, very real. – Dzoba

Answer 2

The CLR doesn't use compressed pointers at the moment. It is possible that the gains in the CLR aren't as much as in Java, because .NET relies a lot on structs to keep allocations low.

.NET interfaces a lot with native code, and the redundant bits of the 4-byte or 8-byte aligned pointers could be used for marking an object pinned among other status flags (note this is currently not implemented like this - probably because it is a compatibility nightmare to implement).

Mordant