-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deps: cherry-pick f4376ec801e1ded from V8 upstream #37225
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pulled over the three commits from this PR on top of my v14.15.4 and can confirm this does indeed fix the yarn segfault :-)
Is it possible to backport it to master first? I suppose it also affects v15.x |
I think the original patch might apply to master but it does land cleanly against 14.15.x. Let me sort out the compilation errors in the test for this PR and then I'll take a look at creating a PR against master (on Monday). |
Original commit message: [heap] Make maximum regular code object size a runtime value. Executable V8 pages include 3 reserved OS pages: one for the writable header and two as guards. On systems with 64k OS pages, the amount of allocatable space left for objects can then be quite smaller than the page size, only 64k for each 256k page. This means regular code objects cannot be larger than 64k, while the maximum regular object size is fixed to 128k, half of the page size. As a result code object never reach this limit and we can end up filling regular pages with few large code objects. To fix this, we change the maximum code object size to be runtime value, set to half of the allocatable space per page. On systems with 64k OS pages, the limit will be 32k. Alternatively, we could increase the V8 page size to 512k on Arm64 linux so we wouldn't waste code space. However, systems with 4k OS pages are more common, and those with 64k pages tend to have more memory available so we should be able to live with it. Bug: v8:10808 Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809 Reviewed-by: Igor Sheludko <[email protected]> Reviewed-by: Georg Neis <[email protected]> Reviewed-by: Ulan Degenbaev <[email protected]> Commit-Queue: Pierre Langlois <[email protected]> Cr-Commit-Position: refs/heads/master@{#70569} Refs: nodejs/help#3202
This commit adds arm64 to test-worker-prof status as this seems to be flaky on arm64 in addition to arm.
f1dae87
to
c44140c
Compare
Original commit message: [heap] Make maximum regular code object size a runtime value. Executable V8 pages include 3 reserved OS pages: one for the writable header and two as guards. On systems with 64k OS pages, the amount of allocatable space left for objects can then be quite smaller than the page size, only 64k for each 256k page. This means regular code objects cannot be larger than 64k, while the maximum regular object size is fixed to 128k, half of the page size. As a result code object never reach this limit and we can end up filling regular pages with few large code objects. To fix this, we change the maximum code object size to be runtime value, set to half of the allocatable space per page. On systems with 64k OS pages, the limit will be 32k. Alternatively, we could increase the V8 page size to 512k on Arm64 linux so we wouldn't waste code space. However, systems with 4k OS pages are more common, and those with 64k pages tend to have more memory available so we should be able to live with it. Bug: v8:10808 Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809 Reviewed-by: Igor Sheludko <[email protected]> Reviewed-by: Georg Neis <[email protected]> Reviewed-by: Ulan Degenbaev <[email protected]> Commit-Queue: Pierre Langlois <[email protected]> Cr-Commit-Position: refs/heads/master@{#70569} PR-URL: #37225 Refs: nodejs/help#3202 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Stewart X Addison <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: James M Snell <[email protected]>
This commit adds arm64 to test-worker-prof status as this seems to be flaky on arm64 in addition to arm. PR-URL: #37225 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Stewart X Addison <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: James M Snell <[email protected]>
Original commit message: [heap] Make maximum regular code object size a runtime value. Executable V8 pages include 3 reserved OS pages: one for the writable header and two as guards. On systems with 64k OS pages, the amount of allocatable space left for objects can then be quite smaller than the page size, only 64k for each 256k page. This means regular code objects cannot be larger than 64k, while the maximum regular object size is fixed to 128k, half of the page size. As a result code object never reach this limit and we can end up filling regular pages with few large code objects. To fix this, we change the maximum code object size to be runtime value, set to half of the allocatable space per page. On systems with 64k OS pages, the limit will be 32k. Alternatively, we could increase the V8 page size to 512k on Arm64 linux so we wouldn't waste code space. However, systems with 4k OS pages are more common, and those with 64k pages tend to have more memory available so we should be able to live with it. Bug: v8:10808 Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809 Reviewed-by: Igor Sheludko <[email protected]> Reviewed-by: Georg Neis <[email protected]> Reviewed-by: Ulan Degenbaev <[email protected]> Commit-Queue: Pierre Langlois <[email protected]> Cr-Commit-Position: refs/heads/master@{#70569} PR-URL: #37225 Refs: nodejs/help#3202 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Stewart X Addison <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: James M Snell <[email protected]>
This commit adds arm64 to test-worker-prof status as this seems to be flaky on arm64 in addition to arm. PR-URL: #37225 Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Stewart X Addison <[email protected]> Reviewed-By: Juan José Arboleda <[email protected]> Reviewed-By: James M Snell <[email protected]>
Refs: nodejs/help#3202