deps: cherry-pick bb4974d from v8 upstream - #9192
Conversation
Sorry, something went wrong.
|
Shouldn't this bump the V8 patch level? |
Sorry, something went wrong.
bnoordhuis
left a comment
There was a problem hiding this comment.
LGTM but can you bump the patch version in v8-version.h and wrap the long lines in the commit log? There is a small typo in the commit log: s/stick/sticky/.
Sorry, something went wrong.
Original commit message: [heap] Properly propagate allocated space during new space evacuaton in MC New space evaucation in MC supports, similar to scavenges, fall back allocation in old space. For new space evacuation we support sticky and non-sticky modes for fallback. The sticky mode essentially removes the capability to allocate in new space while the non-sticky mode only falls back for a single allocation. We use the non-sticky mode for allocations that are too large for a LAB but should still go in new space. When such an allocation fails in new space, we allocate in old space in non-sticky mode as we would still like to reuse the remainder memory in new space. However, in such a case we fail to properly report the space allocated in resulting in a missed recorded slot. BUG=chromium:641270 R=ulan@chromium.org Review-Url: https://codereview.chromium.org/2280943002 Cr-Commit-Position: refs/heads/master@{#38940}
|
Fixed v8 patch version and commit message formatting. |
Sorry, something went wrong.
|
CI: https://ci.nodejs.org/job/node-test-pull-request/4600/ |
Sorry, something went wrong.
|
V8 CI runs seem to be failing with the message "fatal: unable to access 'https://github.com/nodejs/node.git/branches/HEAD/deps/v8/': The requested URL returned error: 410" |
Sorry, something went wrong.
|
Failures on FreeBSD 10 seem unrelated. |
Sorry, something went wrong.
Original commit message: [heap] Properly propagate allocated space during new space evacuaton in MC New space evaucation in MC supports, similar to scavenges, fall back allocation in old space. For new space evacuation we support sticky and non-sticky modes for fallback. The sticky mode essentially removes the capability to allocate in new space while the non-sticky mode only falls back for a single allocation. We use the non-sticky mode for allocations that are too large for a LAB but should still go in new space. When such an allocation fails in new space, we allocate in old space in non-sticky mode as we would still like to reuse the remainder memory in new space. However, in such a case we fail to properly report the space allocated in resulting in a missed recorded slot. BUG=chromium:641270 R=ulan@chromium.org Review-Url: https://codereview.chromium.org/2280943002 Cr-Commit-Position: refs/heads/master@{#38940} PR-URL: #9192 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>
Checklist
Affected core subsystem(s)
deps
Description of change
Original commit message:
[heap] Properly propagate allocated space during new space evacuaton in
MC
New space evaucation in MC supports, similar to scavenges, fall back
allocation in old space.
For new space evacuation we support sticky and non-sticky modes for
fallback. The sticky mode essentially removes the capability to allocate
in new space while the non-sticky mode only falls back for a single
allocation.
We use the non-sticky mode for allocations that are too large for a LAB
but should still go in new space. When such an allocation fails in new
space, we allocate in old space in non-sticky mode as we would still
like to reuse the remainder memory in new space. However, in such a case
we fail to properly report the space allocated in resulting in a missed
recorded slot.
BUG=chromium:641270
R=ulan@chromium.org
Review-Url: https://codereview.chromium.org/2280943002
Cr-Commit-Position: refs/heads/master@{#38940}