- 23 Sep, 2015 1 commit
-
-
julien.gilli authored
BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1363683002 Cr-Commit-Position: refs/heads/master@{#30873}
-
- 22 Sep, 2015 19 commits
-
-
mbrandy authored
Port 1dfac69f 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}
-
mbrandy authored
Port 10c5f2e8 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}
-
mbrandy authored
R=titzer@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/1358193002 Cr-Commit-Position: refs/heads/master@{#30870}
-
mbrandy authored
Port e56f265f 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}
-
adamk authored
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}
-
conradw authored
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}
-
neis authored
R=rossberg BUG= Review URL: https://codereview.chromium.org/1354433004 Cr-Commit-Position: refs/heads/master@{#30866}
-
mlippautz authored
BUG= Review URL: https://codereview.chromium.org/1348763006 Cr-Commit-Position: refs/heads/master@{#30865}
-
hpayer authored
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}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#30863}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#30862}
-
ishell authored
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}
-
bmeurer authored
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}
-
bmeurer authored
Fixes a typo introduced earlier, where we compare the value to heap number map instead of the map loaded previously. TBR=jarin@chromium.org Review URL: https://codereview.chromium.org/1355253002 Cr-Commit-Position: refs/heads/master@{#30859}
-
bmeurer authored
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}
-
bmeurer authored
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}
-
bmeurer authored
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}
-
v8-autoroll authored
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}
-
dpranke authored
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}
-
- 21 Sep, 2015 12 commits
-
-
littledan authored
Turn on some test262 tests that pass now. R=adamk LOG=Y BUG=v8:4285 Review URL: https://codereview.chromium.org/1357233002 Cr-Commit-Position: refs/heads/master@{#30853}
-
bmeurer authored
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}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#30851}
-
mlippautz authored
R=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1360553003 Cr-Commit-Position: refs/heads/master@{#30850}
-
titzer authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1356913002 Cr-Commit-Position: refs/heads/master@{#30849}
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/1345273004 Cr-Commit-Position: refs/heads/master@{#30848}
-
bmeurer authored
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}
-
mythria authored
Removes deprecated functions from the following files: test/cctest/compiler/function-tester.h test/cctest/test-thread-termination.cc test/cctest/test-threads.cc test/cctest/test-transitions.cc test/cctest/test-typedarrays.cc test/cctest/test-types.cc test/cctest/test-typing-reset.cc test/cctest/test-unbound-queue.cc test/cctest/test-unboxed-doubles.cc BUG=v8:4134 LOG=n Review URL: https://codereview.chromium.org/1344583002 Cr-Commit-Position: refs/heads/master@{#30846}
-
chunyang.dai authored
port 8016547c (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}
-
chunyang.dai authored
port 593c655a (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}
-
julien.gilli authored
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}
-
littledan authored
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}
-
- 20 Sep, 2015 1 commit
-
-
alph authored
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}
-
- 19 Sep, 2015 1 commit
-
-
v8-autoroll authored
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}
-
- 18 Sep, 2015 6 commits
-
-
julien.gilli authored
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}
-
mbrandy authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com BUG= Review URL: https://codereview.chromium.org/1345223005 Cr-Commit-Position: refs/heads/master@{#30838}
-
mbrandy authored
Port 8016547c 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}
-
mbrandy authored
Port 593c655a 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}
-
adamk authored
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}
-
adamk authored
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}
-