Hacker News Reader

Comment by tybit | Hacker News Reader

“ A downside to this is that the V8 heap can not be any greater than 4 GB as that is the maximum limit of a 32-bit address space. This is fine for browsers, as the heap doesn’t need to be greater than 4 GB anyway. It becomes a problem with things like node.js that require larger heaps. Because of this, pointer compression is disabled for node.js until a better solution can be figured out.”

It will be interesting to see how this evolves. In the Hotspot JVM(not using fancy GCs at least), heaps up to ~32GB can use pointer compression, as they compress pointers to object offsets instead of memory addresses.

https://stackoverflow.com/questions/25120546/trick-behind-jv...

View on HN

We're definitely interested in exploring this. Unfortunately it's likely a little slower than 4gb PC: Compression right now is basically a no-op, decompression simply being a single add instruction. And it'll fragment memory a little because of the alignment requirements. But surely worth it for where larger heaps are necessary.

Don't fancy x86 addressing modes provide most of those multiplications and offsets with very little IPC penalty?

Yeah, this should be roughly the same overhead as an ADD:

    LEA rDest, [rBase + 8*rPtr]

(The "load effective address" instruction computes an effective address like a load or store would, but just gives the address without doing a memory access.)

AIUI mov supports these things directly[0] and if I read the instruction tables correctly then at least on skylake the latency/throughput is the same for all addressing modes[1]

[0] http://www.c-jump.com/CIS77/ASM/Addressing/lecture.html#R77_... [1] https://www.agner.org/optimize/instruction_tables.pdf (page 238)

Decompression isn't the problem, compression is. Compression is just a mov. Now we need additional shifts.

Also we'll probably lose some cache benefits from compression due to larger alignment.

In general there doesn’t seem to be much use for pointers to specific bytes. Almost any field should be at least 32-bit aligned and when you do need an exact byte, storing an offset from the beginning of the object probably makes more sense.

Any C code which does any kind of parsing or work with buffers almost certainly uses char* as a pointer to bytes.

Interesting portability effects then arise when you have different representations for void / char vs other pointer types.

Reply on news.ycombinator.com