deps: cherry-pick bb4974d from v8 upstream #9192
Closed
Conversation
This file contains 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
matthewloring
added
v8 engine
|
/cc @thealphanerd @nodejs/v8 |
MylesBorins
force-pushed
the
v6.x-staging
branch
from
56368e3
to
8bb346d
Compare
|
Shouldn't this bump the V8 patch level? |
bnoordhuis
approved these changes
Oct 20, 2016
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. |
bnoordhuis
approved these changes
Oct 20, 2016
|
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" |
|
Failures on FreeBSD 10 seem unrelated. |
jasnell
approved these changes
Oct 28, 2016
jasnell
pushed a commit
that referenced
this pull request
Oct 28, 2016
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>
|
Landed in v6.x-staging in 0fcf249 |
Merged
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.
Checklist
make -j8 test(UNIX), orvcbuild test nosign(Windows) passesAffected 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}