We don't need Object::IsSpecFunction anymore, since it only checks for
JSFunction and JSFunctionProxy, but what you actually want to check for
(in case of accessors) is whether the target has a [[Call]] internal
method, which is exactly what Object::IsCallable does.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=rossberg@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1358403002
Cr-Commit-Position: refs/heads/master@{#30875}
Now both Execution::Call and Execution::New can deal with any
kind of target and will raise a proper exception if the target is not
callable (which is not yet spec compliant for New, as we would
have to check IsConstructor instead, which we don't have yet).
Now we no longer need to do any of these weird call/construct
delegate gymnastics in C++, and we finally have a single true
bottleneck for Call/Construct abstract operations in the code
base, with only a few special handlings left in the compilers to
optimize the JSFunction case.
R=jarin@chromium.org
BUG=v8:4430, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1360793002
Cr-Commit-Position: refs/heads/master@{#30874}
Port 1dfac69f1f
Original commit message:
Introduce new builtins Construct and ConstructFunction (in line
with the Call and CallFunction builtins that we already have) as
proper bottleneck for Construct and [[Construct]] on JSFunctions.
Use these builtins to support passing NewTarget from C++ to
JavaScript land.
Long-term we want the CallConstructStub to be used for
gathering feedback on entry to construction chain (i.e. the
initial new Foo), and use the Construct builtins to do the
actual work inside the construction chain (i.e. calling into
super and stuff).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=v8:4430
LOG=n
Review URL: https://codereview.chromium.org/1358203002
Cr-Commit-Position: refs/heads/master@{#30872}
Port 10c5f2e85e
Original commit message:
Slow path for relational comparison of boolean primitive values
now goes through the runtime, which made the slow path even
slower than it already was. So in order to repair the regression,
we just track boolean feedback for comparisons and use that
to generate decent code in Crankshaft (not the best possible
code, but good enough for Crankshaft; TurboFan will be able
to do better on that).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=chromium:534200
LOG=n
Review URL: https://codereview.chromium.org/1362683002
Cr-Commit-Position: refs/heads/master@{#30871}
Port e56f265f6d
Original commit message:
Previously we only collected the known map for equality comparisons. But
if we also collect it for relational comparisons, we can inline a fast
path of ToPrimitive on the objects, which is especially interesting
since both sides have the same map.
For now we only inline a very limited subset of ToPrimitive in
Crankshaft, which is when the receiver map (and its prototype chain)
doesn't have @@toPrimitive, and both valueOf and toString are the
default versions on the %ObjectPrototype%. In this case the relational
comparison would reduce to a string comparison of "[object CLASS]" with
itself and so we can reduce that to a boolean constant plus map checks
on both left and right hand side, plus code dependencies on the
prototype chain. This repairs the regression on box2d.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=chromium:534200
LOG=n
Review URL: https://codereview.chromium.org/1358063005
Cr-Commit-Position: refs/heads/master@{#30869}
This adds the materialized literal count accumulated while parsing the
parameters (in the parser proper) to that accumulated by the preparser.
This should have been caught in cctest/test-parsing, but it's not covered
because the parsing tests call directly into the preparser rather than
using Parser::ParseFunctionLiteral (which fully-parses the parameters
and then calls into the preparser to skip over the function body).
Note that this further-inflates the materialized literal count for
functions with destructured arguments, since some of the counted
literals are actually binding patterns. But that's not specific to
binding patterns in formal parameters: it happens in function bodies, too.
BUG=v8:4400,v8:4407
LOG=n
Review URL: https://codereview.chromium.org/1350913005
Cr-Commit-Position: refs/heads/master@{#30868}
Weak classes can inherit from strong ones again, a strong base class makes
instances strong.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1347243004
Cr-Commit-Position: refs/heads/master@{#30867}
This reduces the pause time of weak cells processing during a full GC.
BUG=
Review URL: https://codereview.chromium.org/1363553002
Cr-Commit-Position: refs/heads/master@{#30864}
With the IC-less global variables accesses the size of the Rotate* functions became small enough to be immediately optimized by Crankshaft which in turn tanked SunSpider/3d-cube.
BUG=chromium:531338
LOG=N
Review URL: https://codereview.chromium.org/1356603005
Cr-Commit-Position: refs/heads/master@{#30861}
Slow path for relational comparison of boolean primitive values
now goes through the runtime, which made the slow path even
slower than it already was. So in order to repair the regression,
we just track boolean feedback for comparisons and use that
to generate decent code in Crankshaft (not the best possible
code, but good enough for Crankshaft; TurboFan will be able
to do better on that).
R=jarin@chromium.org
BUG=chromium:534200
LOG=n
Review URL: https://codereview.chromium.org/1347063004
Cr-Commit-Position: refs/heads/master@{#30860}
Now the StringAddStub can optionally convert it's parameters to strings
(following the rules for the addition operator). This could be further
optimized once we have a ToPrimitiveStub, but it should be sufficient
for the moment.
Also removed the unused Strength parameter to the HStringAdd operator,
because string addition does not depend on language mode.
R=jarin@chromium.org
BUG=v8:4307, chromium:532524
LOG=n
Committed: https://crrev.com/d261849e53fbf8c36efae42d478271f87acff70f
Cr-Commit-Position: refs/heads/master@{#30726}
Review URL: https://codereview.chromium.org/1339053002
Cr-Commit-Position: refs/heads/master@{#30858}
Introduce new builtins Construct and ConstructFunction (in line
with the Call and CallFunction builtins that we already have) as
proper bottleneck for Construct and [[Construct]] on JSFunctions.
Use these builtins to support passing NewTarget from C++ to
JavaScript land.
Long-term we want the CallConstructStub to be used for
gathering feedback on entry to construction chain (i.e. the
initial new Foo), and use the Construct builtins to do the
actual work inside the construction chain (i.e. calling into
super and stuff).
MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
R=jarin@chromium.org
BUG=v8:4430
LOG=n
Review URL: https://codereview.chromium.org/1359583002
Cr-Commit-Position: refs/heads/master@{#30857}
If @@toStringTag is an accessor property, we cannot assume that the result
of calling Object.prototype.toString() for objects with the same map.
R=adamk@chromium.org
BUG=chromium:534200
LOG=n
Review URL: https://codereview.chromium.org/1360723002
Cr-Commit-Position: refs/heads/master@{#30856}
Rolling v8/build/gyp to 01528c7244837168a1c80f06ff60fa5a9793c824
Rolling v8/tools/clang to 3e04436a49a26f4bd2c6f352efcf4c7b10a6d07d
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1360563003
Cr-Commit-Position: refs/heads/master@{#30855}
We need to build parts of v8 with a toolchain that might be different
from both the default (target) toolchain and the regular host toolchain,
because we need the snapshot to have the same bit-width as the target.
V8's build defines a 'snapshot_toolchain' setting for this.
It turns out that we need the value of this toolchain to be exposed
to the Chromium build because some of the test targets (in browser_tests)
depend on d8 and need to be able to built using the same toolchain.
R=brett@chromium.org, jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1350223004
Cr-Commit-Position: refs/heads/master@{#30854}
Previously we only collected the known map for equality comparisons. But
if we also collect it for relational comparisons, we can inline a fast
path of ToPrimitive on the objects, which is especially interesting
since both sides have the same map.
For now we only inline a very limited subset of ToPrimitive in
Crankshaft, which is when the receiver map (and its prototype chain)
doesn't have @@toPrimitive, and both valueOf and toString are the
default versions on the %ObjectPrototype%. In this case the relational
comparison would reduce to a string comparison of "[object CLASS]" with
itself and so we can reduce that to a boolean constant plus map checks
on both left and right hand side, plus code dependencies on the
prototype chain. This repairs the regression on box2d.
R=jkummerow@chromium.org
BUG=chromium:534200
LOG=n
Review URL: https://codereview.chromium.org/1355113002
Cr-Commit-Position: refs/heads/master@{#30852}
This doesn't fix the performance regression mentioned by the bug yet,
but is necessary cleanup to land the fix, and should be separated from
the actual fix.
R=jkummerow@chromium.org
BUG=chromium:534200
LOG=n
Review URL: https://codereview.chromium.org/1345313005
Cr-Commit-Position: refs/heads/master@{#30847}
port 8016547c8e (r30818).
original commit message:
The StringCompareStub used to take its parameters on the (JavaScript)
stack, which made it impossible to use in TurboFan. Actually
StringCompareStub was currently completely unused. This changes the
calling convention to something TurboFan compatible and introduces a
CallInterfaceDescriptor for StringCompareStub. It also changes
HStringCompareAndBranch to use the StringCompareStub instead of using
the full blown CompareICStub for a stupid string comparison.
BUG=
Review URL: https://codereview.chromium.org/1355983003
Cr-Commit-Position: refs/heads/master@{#30845}
port 593c655a3c (r30816).
original commit message:
This removes the weird COMPARE and COMPARE_STRONG JavaScript builtins
and replaces them with a proper C++ implementation in Object::Compare
and appropriate wrappers Object::LessThan, Object::GreaterThan, and
friends that are intended to be used by a true/false returning CompareIC
in the future, as well as the interpreter. As a short-term solution we
provide %Compare and %Compare_Strong entry points for the current
CompareIC that return the appropriate integer values expected by
fullcodegen currently.
Now the Abstract Relational Comparison is also using the correct
ToPrimitive implementation, which properly supports @@toPrimitive.
BUG=
Review URL: https://codereview.chromium.org/1353343002
Cr-Commit-Position: refs/heads/master@{#30844}
mdb_v8, a post-mortem debugging tool for Node.js, allows users to
inspect ScopeInfo structures in order to get more information about
closures.
Currently, it hardcodes the metadata it uses to find this information.
This change allows it to get this metadata from the node binary itself,
and thus to adapt to future changes made to the layout of the ScopeInfo
data structure.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1350843003
Cr-Commit-Position: refs/heads/master@{#30843}
ES2015 specifies very particular semantics for functions defined in blocks.
In strict mode, it is simply a lexical binding scoped to that block. In sloppy
mode, in addition to that lexical binding, there is a var-style binding in
the outer scope, which is overwritten with the local binding when the function
declaration is evaluated, *as long as* introducing ths var binding would not
create a var/let conflict in the outer scope.
This patch implements the semantics by introducing a DelegateStatement, which
is initially filled in with the EmptyStatement and overwritten with the
assignment when the scope is closed out and it can be checked that there is
no conflict.
This patch is tested with a new mjsunit test, and I tried staging it and running
test262, finding that the tests that we have disabled due to lack of Annex B
support now pass.
R=adamk,rossberg
LOG=Y
BUG=v8:4285
Review URL: https://codereview.chromium.org/1332873003
Cr-Commit-Position: refs/heads/master@{#30842}
Upon collection of the stack trace if the current PC falls into
the frame building code, the top frame might be in a non-consistent
state. That leads to some of the frames could be missing from the
stack trace.
The patch makes it check instructions under current PC and if they
look like the frame setup/destroy code, it skips the entire sample.
Support for x86/x64
CG_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_msan_rel
BUG=chromium:529931
LOG=N
Review URL: https://codereview.chromium.org/1348533005
Cr-Commit-Position: refs/heads/master@{#30841}
Rolling v8/build/gyp to cf3170e30578d600b8ec8cd68553cc5e606d42eb
Rolling v8/tools/clang to 76e743dc622478312b66661ad48997b318628cbb
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1357793002
Cr-Commit-Position: refs/heads/master@{#30840}
Since https://codereview.chromium.org/272163002, BitField3 is a raw
uint32 field, and not a SMI anymore.
Update tools/gen-postmortem-metadata.py so that post-mortem tools can
work with versions of V8 that shipped after that change.
This change was merged in github.com/joyent/node right before node
v0.12.0 was released.
R=danno@chromium.org
TEST=mdb_v8, a post-mortem debugging tool running on SmartOS, has been
using this change since Node.js v0.12.0 was released
BUG=
Review URL: https://codereview.chromium.org/1296743003
Cr-Commit-Position: refs/heads/master@{#30839}
Port 8016547c8e
Original commit message:
The StringCompareStub used to take its parameters on the (JavaScript)
stack, which made it impossible to use in TurboFan. Actually
StringCompareStub was currently completely unused. This changes the
calling convention to something TurboFan compatible and introduces a
CallInterfaceDescriptor for StringCompareStub. It also changes
HStringCompareAndBranch to use the StringCompareStub instead of using
the full blown CompareICStub for a stupid string comparison.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1358553002
Cr-Commit-Position: refs/heads/master@{#30837}
Port 593c655a3c
Original commit message:
This removes the weird COMPARE and COMPARE_STRONG JavaScript builtins
and replaces them with a proper C++ implementation in Object::Compare
and appropriate wrappers Object::LessThan, Object::GreaterThan, and
friends that are intended to be used by a true/false returning CompareIC
in the future, as well as the interpreter. As a short-term solution we
provide %Compare and %Compare_Strong entry points for the current
CompareIC that return the appropriate integer values expected by
fullcodegen currently.
Now the Abstract Relational Comparison is also using the correct
ToPrimitive implementation, which properly supports @@toPrimitive.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1356983002
Cr-Commit-Position: refs/heads/master@{#30836}
It's been enabled since M45, which is now well into its stable period,
with no problems reported.
Review URL: https://codereview.chromium.org/1356793002
Cr-Commit-Position: refs/heads/master@{#30835}
This changes the error message for code like:
if (false) let x;
from "Block-scoped declarations (let, const, function, class) not yet supported outside strict mode"
to "Unexpected identifier" (pointing at |x|).
Review URL: https://codereview.chromium.org/1356783002
Cr-Commit-Position: refs/heads/master@{#30834}
Akin to linear scan's TryReuseSpillForPhi, we attempt to merge the
spill ranges of grouped live ranges (which are phi inputs and output),
to avoid inefficient slot-to-slot moves.
BUG=
Review URL: https://codereview.chromium.org/1353023003
Cr-Commit-Position: refs/heads/master@{#30833}
This way we can finally remove the ES5 ToPrimitive builtin from
runtime.js, and the Date Constructor now properly supports
@@toPrimitive for the single argument case as well.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
R=rossberg@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1346893003
Cr-Commit-Position: refs/heads/master@{#30832}
port b5588f48fd (r30767).
original commit message:
There isn't a plan to turn it on soon, so we'll take it out in favor of cleaner code.
BUG=
Review URL: https://codereview.chromium.org/1346043005
Cr-Commit-Position: refs/heads/master@{#30829}
