deps: cherry-pick f4376ec801e1ded from V8 upstream#37225
Closed
danbev wants to merge 2 commits intonodejs:v14.x-stagingfrom
Closed
deps: cherry-pick f4376ec801e1ded from V8 upstream#37225danbev wants to merge 2 commits intonodejs:v14.x-stagingfrom
danbev wants to merge 2 commits intonodejs:v14.x-stagingfrom
Conversation
Contributor
Author
sxa
approved these changes
Feb 4, 2021
Member
sxa
left a comment
There was a problem hiding this comment.
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 :-)
Member
|
Is it possible to backport it to master first? I suppose it also affects v15.x |
Contributor
Author
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
Collaborator
juanarbol
approved these changes
Feb 15, 2021
jasnell
approved these changes
Feb 15, 2021
Collaborator
Contributor
Author
danbev
added a commit
that referenced
this pull request
Feb 16, 2021
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]>
danbev
added a commit
that referenced
this pull request
Feb 16, 2021
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]>
Contributor
Author
MylesBorins
pushed a commit
that referenced
this pull request
Apr 6, 2021
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]>
MylesBorins
pushed a commit
that referenced
this pull request
Apr 6, 2021
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]>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs: nodejs/help#3202