Original commit messages:
v8/v8@a2ab135
[snapshot] Rehash strings after deserialization.
See https://goo.gl/6aN8xA
Bug: v8:6593
Change-Id: Ic8b0b57195d01d41591397d5d45de3f0f3ebc3d9
Reviewed-on: https://chromium-review.googlesource.com/574527
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46732}
v8/v8@182caaf
Do not track transitions for built-in objects.
Objects created during bootstrapping do not need
a transition tree except for elements kind transitions.
Bug: v8:6596
Change-Id: I237b8b2792f201336e1c9731c815095dd06bc182
Reviewed-on: https://chromium-review.googlesource.com/571750
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46693}
Fixes: https://github.com/nodejs/node/issues/14171
PR-URL: https://github.com/nodejs/node/pull/14385
This is a local patch because upstream fixed it differently by moving
large chunks of code out of objects.h. We cannot easily back-port
those changes due to their size and invasiveness.
Fixes: https://github.com/nodejs/node/issues/10388
PR-URL: https://github.com/nodejs/node/pull/12392
Backport-PR-URL: https://github.com/nodejs/node/pull/13574
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
* The following function from <unicode/normlzr.h> is used:
normalize()
* Until ICU 59, <unicode/normlzr.h> is indirectly included, but this changed with the 59 release. Adding this header has been the right thing to do for many years, so it is backwards compatible and fix compilation with recent ICU.
Refs: https://github.com/nodejs/node/issues/13022
PR-URL: https://github.com/nodejs/node/pull/13040
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
HGlobalValueNumberingPhase::CollectSideEffectsOnPathsToDominatedBlock()
used to self-recurse before this commit, causing stack overflows on
systems with small stack sizes. Make it non-recursive by storing
intermediate results in a heap-allocated list.
Fixes: https://github.com/nodejs/node/issues/11991
PR-URL: https://github.com/nodejs/node/pull/12460
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
See the commit log of the reverted commit: it's a semver-minor change
that can land in the next minor release.
This reverts commit 47cbb88ac5929ce6ba17f681785034dd019ce063.
Original commit message:
Don't treat catch scopes as possibly-shadowing for sloppy eval
Scope analysis is over-conservative when treating variable
resolutions as possibly-shadowed by a sloppy eval. In the attached
bug, this comes into play since catch scopes have different behavior
with respect to the "calls eval" in eager vs lazy compilation (in
the latter, they are never marked as "calls eval" because
CatchContexts don't have an associated ScopeInfo).
This patch changes the scope-type check to also eliminate a few
other cases where shadowing isn't possible, such as non-declaration
block scopes.
BUG=chromium:608279
LOG=n
Committed:
https://crrev.com/75f2d65f003ebb22815489e9970913ba37234f1b
Cr-Commit-Position: refs/heads/master@{#36046}
Fixes: #12308
PR-URL: https://github.com/nodejs/node/pull/12535
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
This commit adds lldbinit files from upstream V8 and also adds these so
that they get installed when `make install` is run.
Original commit message:
[tools] add lldbinit
The goal of this commit is to add the equivalent to gdbinit but
for lldb. I've tried to replicate the commands as close as possible
but I'm unsure about the jss command and hoping to get some feedback
on it in addition to the bta command which I'm not sure how/when
this could be used. This is probably just inexperience on my part.
The lldbinit file can be placed into a directory prefixed with dot
(.lldbinit) and the python script is currently expected to be in the
same directory. The path to the script can be changed manually if
needed as well.
NOTRY=true
Review-Url: https://codereview.chromium.org/2758373002
Cr-Commit-Position: refs/heads/master@{#44136}
PR-URL: https://github.com/nodejs/node/pull/12061
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Original commit message:
Trigger OOM crash if no memory returned in v8::ArrayBuffer::New and v…
…8::SharedArrayBuffer::New.
This API does not allow reporting failure, but we should crash rather than have
the caller get an ArrayBuffer that isn't properly set up.
BUG=chromium:681843
Review-Url: https://codereview.chromium.org/2641953002
Cr-Commit-Position: refs/heads/master@{#42511}
PR-URL: https://github.com/nodejs/node/pull/11940
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Original commit message:
Properly handle holes following spreads in array literals
Before this change, the spread desugaring would naively call
`%AppendElement($R, the_hole)` and in some cases $R would have
a non-holey elements kind, putting the array into the bad state
of exposing holes to author code.
This patch avoids calling %AppendElement with a hole, instead
simply incrementing $R.length when it sees a hole in the literal
(this is safe because $R is known to be an Array). The existing
logic for elements transitions takes care of giving the array a
holey ElementsKind.
BUG=chromium:644215
Review-Url: https://codereview.chromium.org/2321533003
Cr-Commit-Position: refs/heads/master@{#39294}
Fixes: https://github.com/nodejs/node/issues/12018
PR-URL: https://github.com/nodejs/node/pull/12037
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Original commit message:
Reduce the memory footprint of expression classifiers
This patch attempts to reduce the (stack) memory footprint of
expression classifiers. Instead of keeping space in each
classifier for all possible error messages that will
(potentially) be reported, if an expression turns out to be
a pattern or a non-pattern, such error messages are placed in
a list shared by the FunctionState and each classifier keeps a
couple of indices in this list. This requires that classifiers
are used strictly in a stack-based fashion, which is also in line
with my previous patch for revisiting non-pattern rewriting.
R=adamk@chromium.org
BUG=chromium:528697
Review-Url: https://codereview.chromium.org/1708193003
Cr-Commit-Position: refs/heads/master@{#36897}
Fixes: https://github.com/nodejs/node/issues/11480
PR-URL: https://github.com/nodejs/node/pull/11483
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Remove the new method that was introduced in the back-port of
v8/v8@306c412c ("[api] Expose FunctionCallbackInfo::NewTarget")
so that the meat of the patch can land in a patch release.
This commit can be reverted again in the next minor release.
Fixes: https://github.com/nodejs/node/issues/9288
PR-URL: https://github.com/nodejs/node/pull/9293
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Original commit message:
When instantiating a subclassed API function, the instance cache
is avoided. There is currently no direct API yet to instantiate
a Template while passing in a new.target. It probably makes sense
to extend ObjectTemplate::NewInstance to accept a new.target, in
line with Reflect.construct.
BUG=v8:3330, v8:5001
Review-Url: https://codereview.chromium.org/1972613002
Cr-Commit-Position: refs/heads/master@{#36179}
Fixes: https://github.com/nodejs/node/issues/9288
PR-URL: https://github.com/nodejs/node/pull/9293
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
The patch has been modified to maintain ABI compatibility. The original
change removes the v8::FunctionCallbackInfo<T>::is_construct_call_ field
from deps/v8/include/v8.h. The field is set directly by JIT-ted code so
the removal of those code paths has been backed out as well.
Original commit message:
[api] Expose FunctionCallbackInfo::NewTarget
This is needed by Blink to implement the Custom Elements spec.
BUG=v8:4261
LOG=y
Review-Url: https://codereview.chromium.org/1910253005
Cr-Commit-Position: refs/heads/master@{#35833}
Fixes: https://github.com/nodejs/node/issues/9288
PR-URL: https://github.com/nodejs/node/pull/9293
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Don't try to optimize known-unoptimizable functions when --always-opt
is specified on the command line, it makes Crankshaft emit wrong code.
This was fixed upstream when improved WASM support was introduced but
that specific change can't be back-ported because it depends on prior
work that doesn't exist in V8 5.1. Ergo, I decided to redo the fix
from scratch.
PR-URL: https://github.com/nodejs/node/pull/9293
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Orignial commit message:
Abort in delete operators that shouldn't be called.
Section 3.2 of the C++ standard states that destructor
definitions implicitly "use" operator delete functions.
Therefore, these operator delete functions must be
defined even if they are never called by user code
explicitly.
http://www.open-std.org/JTC1/SC22/WG21/docs/
cwg_defects.html#261
gcc allows them to remain as empty definitions. However,
not all compilers allow this. (e.g. xlc on zOS). This pull
request creates definitions which if ever called, result
in an abort.
R=danno@chromium.org,jochen@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2588433002
Cr-Commit-Position: refs/heads/master@{#41981}
PR-URL: https://github.com/nodejs/node/pull/10546
Reviewed-By: James M Snell <jasnell@gmail.com>
Fixed a small error that manifests when --debug is specified. This
seems to have been introduced during the backport #9422.
Ref: https://github.com/nodejs/node/pull/9422
PR-URL: https://github.com/nodejs/node/pull/10525
Reviewed-By: ofrobots - Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
Original commit message:
Rewrite scopes in computed properties in destructured parameters
While we properly handled scopes of initializers in destructured
parameters,
we never did the right thing for computed properties. This patch
fixes that
by factoring out PatternRewriter's scope rewriting logic and calls
it for the computed property case.
BUG=chromium:620119
Review-Url: https://codereview.chromium.org/2084103002
Cr-Commit-Position: refs/heads/master@{#37228}
Fixes: https://github.com/nodejs/node/issues/10347
PR-URL: https://github.com/nodejs/node/pull/10386
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.
TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.
R=yangguo@chromium.org
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40592}
PR-URL: https://github.com/nodejs/node/pull/10169
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: ofrobots - Ali Ijaz Sheikh <ofrobots@google.com>
Original Commit Message:
Previously, any expressions inside destructuring patterns in a catch
would be parsed in the surrounding scope, instead of in the catch's
scope. This change fixes that by entering not only the catch scope,
but also the block scope inside it.
R=neis@chromium.org
BUG=v8:5106, v8:5112
Review-Url: https://codereview.chromium.org/2110193002
Cr-Commit-Position: refs/heads/master@{#37415}
PR-URL: https://github.com/nodejs/node/pull/9173
Reviewed-By: jasnell - James M Snell <jasnell@gmail.com>
Reviewed-By: ofrobots - Ali Ijaz Sheikh <ofrobots@google.com>
Original Commit Message:
"build: cherry pick V8 change for windows DLL support"
This reverts commit 92ecbc4edc.
The original commit did not include the entire changeset
PR-URL: https://github.com/nodejs/node/pull/9610
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Original commit message:
Don't skip hole checks inside patterns in parameter lists
Previously, b6e9f625c17f3a688139426771e2cb34fbdcb46e fixed self-assignment
in parameters to throw. But it failed to deal with the case of
destructuring with defaults. This patch extends that previous approach
to always treat the end of a parameter as its initializer position,
whether it has an initializer or not.
This is the minimal change to make it easy to merge; a follow-up
will rename the field of Parameter from "initializer_end_position"
to "end_position".
BUG=v8:5454
Review-Url: https://codereview/chromium.org/2390943002
Cr-Commit-Position: refs/heads/master@{#39962}
PR-URL: https://github.com/nodejs/node/pull/9138
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: jasnell - James M Snell <jasnell@gmail.com>
Original Commit Message:
[ic] Don't call LookupIterator::GetStoreTarget() when receiver is not a JSReceiver.
BUG=chromium:619166,chromium:625155
Review-Url: https://codereview.chromium.org/2175273002
Cr-Commit-Position: refs/heads/master@{#38018}
PR-URL: https://github.com/nodejs/node/pull/9422
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: jasnell - James M Snell <jasnell@gmail.com>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
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: https://github.com/nodejs/node/pull/9192
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
Rewrite scopes of non-simple default arguments
Default parameters have additional declaration block scopes inserted
around them when something in the function scope calls eval. This
patch sets the parent scope of the expressions introduced due to
those defaults to the new block scope.
R=adamk
BUG=chromium:616386
Review-Url: https://codereview.chromium.org/2077283004
Cr-Commit-Position: refs/heads/master@{#37198}
PR-URL: https://github.com/nodejs/node-private/pull/80
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The patch should have been bumped in aafc314 but it was missed.
Ref: aafc314a83
Ref: https://github.com/nodejs/node/pull/8673
PR-URL: https://github.com/nodejs/node/pull/8851
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Original commit message:
Revert of Put RegExp js code in strict mode (patchset #2 id:20001
of https://codereview.chromium.org/1776883005/ )
Reason for revert:
Found to break SAP Web IDE, and these semantics are not shipped
in any other browser.
Revert to legacy semantics while assessing web compatibility.
BUG=chromium:624318
Original issue's description:
> Put RegExp js code in strict mode
>
> src/js/regexp.js was one of the few files that was left in sloppy
> mode. The ES2017 draft specification requires that writes to
> lastIndex throw when the property is non-writable, and test262
> tests enforce this behavior. This patch puts that file in strict
> mode.
>
> BUG=v8:4504
> R=yangguo@chromium.org
> LOG=Y
>
> Committed: https://crrev.com/80b1b2a45bbd9bf3d08e4e6516acfaaa8f438213
> Cr-Commit-Position: refs/heads/master@{#34801}
TBR=yangguo@chromium.org,adamk@chromium.org
Review-Url: https://codereview.chromium.org/2112713003
Cr-Commit-Position: refs/heads/master@{#37449}
PR-URL: https://github.com/nodejs/node/pull/8673
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Add back the no-op harmony shipping flags that were removed in V8 5.1
to increase compatibility with V8 5.0 that we had been shipping before
v6.5.0. These flags do nothing.
Fixes: https://github.com/nodejs/node/issues/8388
Ref: https://github.com/nodejs/node/pull/8395
PR-URL: https://github.com/nodejs/node/pull/8445
Reviewed-By: addaleax - Anna Henningsen <anna@addaleax.net>
Reviewed-By: thealphanerd - Myles Borins <myles.borins@gmail.com>
Reviewed-By: jasnell - James M Snell <jasnell@gmail.com>
Reviewed-By: evanlucas - Evan Lucas <evanlucas@me.com>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Original commit message:
Make FieldType::None() non-nullptr value to avoid undefined behaviour
When FieldType::None() returns a cast Smi::FromInt(0), which translates
as nullptr, the FieldType::IsNone() check becomes equivalent to
`this == nullptr` which is not allowed by the standard and
therefore optimized away as a false constant by GCC 6.
This has lead to crashes when invoking methods on FieldType::None().
Using a different Smi constant for FieldType::None() makes the compiler
always include a comparison against that value. The choice of these
constants has no effect as they are effectively arbitrary.
BUG=https://github.com/nodejs/node/issues/8310
Review-Url: https://codereview.chromium.org/2292953002
Cr-Commit-Position: refs/heads/master@{#39023}
Fixes: https://github.com/nodejs/node/issues/8310
PR-URL: https://github.com/nodejs/node/pull/8411
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Original commit message:
[Debugger] Fix StepNext over function with caught exception
Without CL debugger on StepNext adds breakpoint to function where
throw instruction is located. In case of StepNext we will skip pause
in this function because StepNext shouldn't break in a deeper frame.
BUG=chromium:604495
R=yangguo@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1894263002
Cr-Commit-Position: refs/heads/master@{#35627}
Fixes: https://github.com/nodejs/node/issues/7219
PR-URL: https://github.com/nodejs/node/pull/8099
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Pick up an upstream bugfix for https://crbug.com/621926 and bump V8
version to 5.1.281.80.
Original commit message for 588e15c:
Fixes a bug in cmpw.
The opcodes for 'cmpw r/m16, r16' and 'cmpw r16, r/m16' were
swapped, causing a few issues when less than/greater than
comparison were performed.
Adds a regression test.
BUG=621926
Committed: https://crrev.com/efa7095e3e360fbadbe909d831ac11b268ca26b0
Review-Url: https://codereview.chromium.org/2103713003
Cr-Original-Commit-Position: refs/heads/master@{#37339}
Cr-Commit-Position: refs/heads/master@{#37345}
Original commit message for c0d4bb8:
Fixes a wrong use of Operand in a test.
Operand(reg) -> reg
Operand(reg, 0) -> [reg]
BUG=
Review-Url: https://codereview.chromium.org/2111503002
Cr-Commit-Position: refs/heads/master@{#37370}
PR-URL: https://github.com/nodejs/node/pull/8038
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: ofrobots - Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: mhdawson - Michael Dawson <michael_dawson@ca.ibm.com>
Original commit message:
[build] Add force_dynamic_crt option to build a static library with /…
…MD on windows
Adds option to build a V8 library statically, but with the options on
windows that allows it to be subsequently included in another DLL. On
Windows this is required for it to correclty link against the correct
C++ runtime. Require for our Node.js shared library build.
Reference: nodejs/node#7487
BUG=
R=machenbach@chromium.org, michael_dawson@ca.ibm.com
Committed: https://crrev.com/9cf88c1c364cf76c1e745aa63196768435e8ef5d
Review-Url: https://codereview.chromium.org/2149963002
Cr-Original-Commit-Position: refs/heads/master@{#37814}
Cr-Commit-Position: refs/heads/master@{#37856}
PR-URL: https://github.com/nodejs/node/pull/7802
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Original commit message:
[regexp] Fix case-insensitive matching for one-byte subjects.
The bug occurs because we do not canonicalize character class ranges
before adding case equivalents. While adding case equivalents, we abort
early for one-byte subject strings, assuming that the ranges are sorted.
Which they are not.
R=marja@chromium.org
BUG=v8:5199
Review-Url: https://codereview.chromium.org/2159683002
Cr-Commit-Position: refs/heads/master@{#37833}
Fixes: https://github.com/nodejs/node/issues/7708
PR-URL: https://github.com/nodejs/node/pull/7833
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: ofrobots - Ali Ijaz Sheikh <ofrobots@google.com>
Original commit message:
S390:Update inline asm constraint in test-platform
The GetStackPointer() routine in test-platform uses an inline
assembly code to store the current stack pointer value into a static
variable sp_addr. The existing asm code for S390 uses an ST/STG
instruction, with the memory operand associated with the general ('=g')
constraint to sp_addr.
On GCC 4.8.5, the GCC compiler got confused and treated sp_addr as
an integer operand instead of memory operand, resulting in a store
being emitted that writes to an invalid meory location.
Given the specific store instructions being inlined here, we should
restict the sp_addr operand to explicitly be a memory operand using '=m'
instead of '=g'.
R=bmeurer@chromium.org,jkummerow@chormium.org,rmcilroy@chromium.org,yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2158523002
Cr-Commit-Position: refs/heads/master@{#37809}
Fixes: https://github.com/nodejs/node/issues/7659
PR-URL: https://github.com/nodejs/node/pull/7771
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Remove the `_malloced_memory` field from the `HeapStatistics`
class to achieve full ABI compatibility with V8 5.0.
Ref: https://github.com/nodejs/node/pull/7016
PR-URL: https://github.com/nodejs/node/pull/7526
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>