3

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?

Julien Lebosquain
  • 40,639
  • 8
  • 105
  • 117
  • 2
    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. – Hans Passant Jul 30 '11 at 14:47
  • 3
    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.) – Trent Gray-Donald Aug 02 '11 at 13:11
  • 1
    @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. – Sam Harwell Nov 08 '14 at 08:42
  • Certainly it'll improve performance in some cases. For example look at the [benchmarks for x32 ABI](https://sites.google.com/site/x32abi/) 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 – phuclv Nov 04 '16 at 17:13

1 Answers1

-4

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).

foxy
  • 7,599
  • 2
  • 30
  • 34
  • 3
    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. – Trent Gray-Donald Aug 02 '11 at 13:06
  • 2
    To highlight "better cache efficiency": L2 cache is a few megabytes, and stuff outside the cache takes ~100 cycles to access. – Blaisorblade Jan 26 '14 at 22:03
  • 3
    -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. – Sam Harwell Nov 08 '14 at 08:39