Official Node.js build with pointer compression enabled
Summary
This is a fresh tracking issue to try to give pointer compression (PC) for an officially shipped Node.js build some renewed traction, as the previous tracking issue was closed by @cjihrig with "If anyone needs this issue, please open a new one." This is that new issue.
I am not familiar with the internal build/release machinery, so I cannot judge exactly what needs to happen here. I am opening this mainly because the topic seems to have stalled, while there is now concrete evidence it works, and I would like to see if it can move forward again.
It picks up two now-inactive threads:
Since those threads went quiet, the key technical blocker has moved forward: IsolateGroups landed (nodejs/node#60254, merged 2025-10-17). That removes the historic "process-wide 4 GB cage" objection by giving each isolate group its own pointer cage. With that in place, the conversation about an official build seems worth reopening.
Why now
Concrete real-world demand: memory-constrained / embedded Linux
We run Node.js on memory-constrained embedded Linux hardware (arm64), where the V8 heap footprint is a hard limiting factor. RAM is fixed and not expandable, so every byte the runtime saves is headroom we can give back to the application. Cutting the heap roughly in half (as the Platformatic numbers show) directly translates into running more, or larger, workloads on the same device, and into fewer out-of-memory failures.
For this class of deployment the typical objection ("just buy more memory") does not apply, and the 4 GB-per-isolate cap is a non-issue. This is the kind of workload that benefits most from an official, maintained PC build, rather than each vendor maintaining their own breakage-prone fork.
Open question
Given that IsolateGroups have landed and a working, benchmarked PC build now exists, what would it actually take to get an official Node.js PC build moving again, and how can we give this effort some traction?
Official Node.js build with pointer compression enabled
Summary
This is a fresh tracking issue to try to give pointer compression (PC) for an officially shipped Node.js build some renewed traction, as the previous tracking issue was closed by @cjihrig with "If anyone needs this issue, please open a new one." This is that new issue.
I am not familiar with the internal build/release machinery, so I cannot judge exactly what needs to happen here. I am opening this mainly because the topic seems to have stalled, while there is now concrete evidence it works, and I would like to see if it can move forward again.
It picks up two now-inactive threads:
Since those threads went quiet, the key technical blocker has moved forward: IsolateGroups landed (nodejs/node#60254, merged 2025-10-17). That removes the historic "process-wide 4 GB cage" objection by giving each isolate group its own pointer cage. With that in place, the conversation about an official build seems worth reopening.
Why now
node-caged(https://github.com/platformatic/node-caged), pre-built multi-arch (amd64/arm64) Docker images for Node.js 25 and 26 with pointer compression + IsolateGroups enabled, with published end-to-end benchmarks: https://blog.platformatic.dev/we-cut-nodejs-memory-in-half. This shows a PC build on current Node.js is viable today and delivers a large, measurable benefit.Concrete real-world demand: memory-constrained / embedded Linux
We run Node.js on memory-constrained embedded Linux hardware (arm64), where the V8 heap footprint is a hard limiting factor. RAM is fixed and not expandable, so every byte the runtime saves is headroom we can give back to the application. Cutting the heap roughly in half (as the Platformatic numbers show) directly translates into running more, or larger, workloads on the same device, and into fewer out-of-memory failures.
For this class of deployment the typical objection ("just buy more memory") does not apply, and the 4 GB-per-isolate cap is a non-issue. This is the kind of workload that benefits most from an official, maintained PC build, rather than each vendor maintaining their own breakage-prone fork.
Open question
Given that IsolateGroups have landed and a working, benchmarked PC build now exists, what would it actually take to get an official Node.js PC build moving again, and how can we give this effort some traction?