Path to adding a Tier 2 build with pointer compression enabled #3204
Comments
|
I think two questions we should get feedback on to start are:
|
|
As a Node.js TSC and Releaser, I'm +1. I don't see it impacting the release workflow directly. However, might make sense to produce a release candidate for LTS versions first (optional) |
Yes, I have concerns about confusion to end users in producing a second Linux download, particularly as I seem to recall concerns about ABI compatibility between regular builds and pointer compression enabled ones (think about ecosystem packages using prebuilds, for example). |
|
@richardlau would you feel better about only adding pointer compression to the CI so that we can at least have more confidence in the existing unofficial build? |
|
@cjihrig my response was specifically to the quoted question. I'm neutral on adding another job to the CI. |
|
Adding another job to the CI seems resonable to me as we already have machines of the required type available and my first guess is that we would not need additional machines to support the one extra job. |
|
@mhdawson so what would be the next step to add the CI job? I'm happy to help, but don't know where/how to get started. |
|
I don't see any objections to adding a CI job, so I'll set up a job Colin can edit/work on and then we can take it from there. It probably will mostly be a clone of some other job. |
|
Added this job with @cjihrig - https://ci.nodejs.org/job/node-test-commit-linux-pointer-compression. Just letting it run to confirm it passes and then will add to the daily main run. |
|
To answer a question people might ask we did not add as a containerized build as I was not sure how to do that and only have it run in the nightly. |
|
Configured the job so that @cjihrig can edit/modify the job in cases changes/fixes are needed. |
|
Had to fixup the addition to the daily main job as it did not run today. Believe it should run next time. |
|
@mhdawson thanks for the help getting the pointer compression job into the daily job. It looks like it has passed every time it has run for the past few weeks with the exception of one time when GitHub changed the key. As a next step, does it make sense to add pointer compression to the CI for pull requests on |
|
The part about only running on v19 and later is one that may require something special. @richardlau I don't think the VersionSelectorSecript can help us on this one right? |
|
That is exactly what the VersionSelectorScript is intended for. However it works on labels (specifically on a build parameter named "nodes"), so you may need to rework the job and/or introduce new labels. |
|
@mhdawson I don't really know what the VersionSelectorScript is, but is it possible to use it to try to move this forward? Happy to help however I can. |
|
@cjihrig maybe we can get together and work on it together for an hour or so. Could you send an invitation with some candidate times? |
|
FWIW https://ci.nodejs.org/job/node-test-commit-linux-pointer-compression has been broken since last week. |
|
I'm not sure I understand why pointer compression would be a tier 2 build instead of the default. How many people are using 4GB of memory in Node, per thread? They're the special case, not the rest of us who are using a handful of gigabytes per process. |
|
The build after v21 seems broken. https://unofficial-builds.nodejs.org/download/release/v21.1.0/node-v21.1.0-linux-x64-pointer-compression.tar.xz The pointer-compression v21.0.0 error same as above. The pointer-compression v20.9.0 works fine. Official v21.1.0 works fine. |
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292
The build was broken by the V8 update. I put up a fix here: nodejs/node#50680 |
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292 PR-URL: #50680 Refs: v8/v8@475c8cd Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292 PR-URL: #50680 Refs: v8/v8@475c8cd Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292 PR-URL: nodejs#50680 Refs: v8/v8@475c8cd Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292 PR-URL: nodejs#50680 Refs: v8/v8@475c8cd Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292 PR-URL: #50680 Refs: v8/v8@475c8cd Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292 PR-URL: #50680 Refs: v8/v8@475c8cd Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292 PR-URL: #50680 Refs: v8/v8@475c8cd Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The V8 API requires entering an isolate before using it. We were often not doing this, which worked fine in practice. However when (multi-cage) pointer compression is enabled, the correct isolate needs to be active in order to decompress pointers correctly, otherwise it causes crashes. Fix this by sprinkling in some calls to v8::Isolate::Scope::Scope where they were missing. This also introduces RAIIIsolateWithoutEntering which is used in JSONParser to avoid otherwise exposing the Isolate::Scope outside of the class. Tested by compiling with `--experimental-enable-pointer-compression` locally and running all tests. Refs: nodejs/build#3204 (comment) Refs: https://bugs.chromium.org/p/v8/issues/detail?id=14292 PR-URL: #50680 Refs: v8/v8@475c8cd Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
|
I'd love to be able to use an official build that enables pointer compression on mac. Would that need a separate build? |
|
yes |
|
Did we give up on pointer compression? I've been unable to try it out. Haven't been able to find a recent build nor have been able to figure out how to create a build myself. Hard to give feedback (for anyone) with the current state of things. |
Nobody appears to be paying any attention to it.
|
|
No, we haven't given up and definitely still are paying attention. Cloudflare has engaged a contract with Igalia to look at a path that hopeful would enable, in part, Node.js to enable pointer compression by default in the future. Specifically, one of the limiting factors with enabling pointer compression to this point has been the strict limit of a single 4gb pointer cage per-process. Limiting the entire process to a single 4gb limit would be too much of a breaking change. To support the alternative configuration we have in Cloudflare Workers, for a different use case that touches on the same parts of v8, Igalia is working on a way to enable multiple pointer cages per process. We call the new API an While it would still definitely be a semver-major and potentially breaking change, I think this approach would make it far more likely that we can enable pointer compression by default in Node.js or at least provide a release distribution with pointer compression enabled. |
FWIW this is not a problem for us. I don't think it's a problem for a majority of users. IMHO two separate builds would be fine. Advanced users can use the pointer compression build. |
|
In the past, I thought we (Platformatic) could sponsor some of this infra work, but startup life got in the way, and this is not a priority anymore. We would definitely use a Node.js build with pointer compression enabled, but the main driver for investing to make it happen is gone. |
|
My hope is that the new |
At the risk of beating a dead horse here I have to agree. The max-old-space-size defaults to 2GB on 64bit systems and I’m willing to bet most node developers have not had a use case to increase this. Even having pointer compression be the default would increase the default heap limit 2x and advanced developers could just switch to the non-compressed build for use cases requiring more heap space. What @jasnell is working on sounds very interesting and promising. But I hope we can get the pointer compression build back on track regardless. |
|
@jasnell What do you mean by well beyond 4GB? If you have lots of object graphs it's entirely possible for 6GB heap to comfortably fit into 4GB with compression enabled. Also I haven't heard anybody petitioning for eliminating 64 bit pointers. The argument is which is the default case and which is the special case. Right now it's very much backward from reality. |
@ronag I would take the opposite conclusion from this. If 4GB cage isn't a problem for most users, then the advanced users should be the ones looking at the uncompressed build, not the other way around. |
|
I've talked with folks that run in excess of 20gb heaps in certain extreme cases. I think Netflix has also seen this but I'd need to confirm again. I do think the excessively sized heaps are not the norm and experience has shown that the vast majority of cases can fit well within a 4gb compressed heap. |
|
@cjihrig completed? |
|
No. Clearing my issues list. If anyone needs this issue, please open a new one. |
This is a follow up to nodejs/TSC#790. The project currently creates unofficial builds for Linux with pointer compression enabled. With pointer compression enabled, the
mainbranch appears to pass the test suite (at least on macOS where I tested). From what I can tell, v19 and earlier are not in such good shape.We are interested in getting pointer compression into the CI, and eventually hopefully get it to Tier 2 status (on Linux would be enough). cc: @nodejs/releasers.
I think the first step would be getting this into the CI so that we can have more confidence in the current unofficial build. Unfortunately, I don't have the slightest idea what needs to happen to add a new CI target - but I am willing to do the work if someone can provide guidance.
cc: @mhdawson @mcollina
The text was updated successfully, but these errors were encountered: