- 24 Sep, 2015 7 commits
-
-
bmeurer authored
There was already a bit on the Map named "function with prototype", which basically meant that the Map was a map for a JSFunction that could be used as a constructor. Now this CL generalizes that bit to IsConstructor, which says that whatever (Heap)Object you are looking at can be used as a constructor (i.e. the bit is also set for bound functions that can be used as constructors and proxies that have a [[Construct]] internal method). This way we have a single chokepoint for IsConstructor checking, which allows us to get rid of the various ways in which we tried to guess whether something could be used as a constructor or not. Drive-by-fix: Renamed IsConstructor on FunctionKind to IsClassConstructor to resolve the weird name clash, and the IsClassConstructor name also matches the spec. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg R=jarin@chromium.org, rossberg@chromium.org BUG=v8:4413, v8:4430 LOG=n Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54 Cr-Commit-Position: refs/heads/master@{#30900} Review URL: https://codereview.chromium.org/1358423002 Cr-Commit-Position: refs/heads/master@{#30902}
-
bmeurer authored
Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ ) Reason for revert: Failed on Fuzzer and MIPS bot. Original issue's description: > [es6] Introduce spec compliant IsConstructor. > > There was already a bit on the Map named "function with prototype", > which basically meant that the Map was a map for a JSFunction that could > be used as a constructor. Now this CL generalizes that bit to > IsConstructor, which says that whatever (Heap)Object you are looking at > can be used as a constructor (i.e. the bit is also set for bound > functions that can be used as constructors and proxies that have a > [[Construct]] internal method). > > This way we have a single chokepoint for IsConstructor checking, which > allows us to get rid of the various ways in which we tried to guess > whether something could be used as a constructor or not. > > Drive-by-fix: Renamed IsConstructor on FunctionKind to > IsClassConstructor to resolve the weird name clash, and the > IsClassConstructor name also matches the spec. > > R=jarin@chromium.org, rossberg@chromium.org > BUG=v8:4430 > LOG=n > > Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54 > Cr-Commit-Position: refs/heads/master@{#30900} TBR=jarin@chromium.org,rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4430 Review URL: https://codereview.chromium.org/1360403002 Cr-Commit-Position: refs/heads/master@{#30901}
-
bmeurer authored
There was already a bit on the Map named "function with prototype", which basically meant that the Map was a map for a JSFunction that could be used as a constructor. Now this CL generalizes that bit to IsConstructor, which says that whatever (Heap)Object you are looking at can be used as a constructor (i.e. the bit is also set for bound functions that can be used as constructors and proxies that have a [[Construct]] internal method). This way we have a single chokepoint for IsConstructor checking, which allows us to get rid of the various ways in which we tried to guess whether something could be used as a constructor or not. Drive-by-fix: Renamed IsConstructor on FunctionKind to IsClassConstructor to resolve the weird name clash, and the IsClassConstructor name also matches the spec. R=jarin@chromium.org, rossberg@chromium.org BUG=v8:4430 LOG=n Review URL: https://codereview.chromium.org/1358423002 Cr-Commit-Position: refs/heads/master@{#30900}
-
chunyang.dai authored
port 1dfac69f (r30857). 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). BUG= Review URL: https://codereview.chromium.org/1362573002 Cr-Commit-Position: refs/heads/master@{#30899}
-
chunyang.dai authored
port c610a222 (r30849). original commit message: BUG= Review URL: https://codereview.chromium.org/1362783003 Cr-Commit-Position: refs/heads/master@{#30898}
-
chunyang.dai authored
port e56f265f (r30852). 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. BUG= Review URL: https://codereview.chromium.org/1342243005 Cr-Commit-Position: refs/heads/master@{#30897}
-
v8-autoroll authored
Rolling v8/tools/clang to 1cde9025c16dfc3e23be2db010b24f657c255b4c TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1359983006 Cr-Commit-Position: refs/heads/master@{#30896}
-
- 23 Sep, 2015 23 commits
-
-
bmeurer authored
Introduce a new macro TO_STRING that maps to %_ToString and use that instead of calling into any of the ToString/NonStringToString JavaScript builtins. Also remove the TO_STRING_INLINE macro, which is basically obsolete with %_ToString. We still have a few uses of ToString left (via the utils export mechanism), where we need to investigate whether we will tank badly if we replace them with TO_STRING as well. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg R=yangguo@chromium.org BUG=v8:4307 LOG=n Review URL: https://codereview.chromium.org/1323543002 Cr-Commit-Position: refs/heads/master@{#30895}
-
gdeepti authored
Remove sumOfAbsoluteDifferences functions. BUG=v8:4124 LOG=Y R=bbudge@chromium.org, littledan@chromium.org Review URL: https://codereview.chromium.org/1356413002 Cr-Commit-Position: refs/heads/master@{#30894}
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1365613002 Cr-Commit-Position: refs/heads/master@{#30893}
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1356363004 Cr-Commit-Position: refs/heads/master@{#30892}
-
mlippautz authored
We not keep track of the histogram as we process values and do not wait until printing the histogram. Furthermore processing the histogram is not O(n) for n values. BUG= Review URL: https://codereview.chromium.org/1364733002 Cr-Commit-Position: refs/heads/master@{#30891}
-
bmeurer authored
For string wrappers (JSValue instances with [[StringData]] internal fields), we can shortcirciut the ToPrimitive if (a) the {input} map matches the initial map of the String function, (b) the {input} [[Prototype]] is the unmodified %StringPrototype% (i.e. no one monkey-patched toString, @@toPrimitive or valueOf), and (c) the %ObjectPrototype% (i.e. the [[Prototype]] of the %StringPrototype%) is also unmodified, that is no one sneaked a @@toPrimitive into the %ObjectPrototype%. If all these assumptions hold, we can just take the [[StringData]] value and return it. This just repairs a regression introduced by removing the weird (and broken) intrinsic %_IsStringWrapperSafeForDefaultValue, which was intendend to something similar to this, although less efficient and wrong in the presence of @@toPrimitive. Long-term we might want to move into the direction of having a ToPrimitiveStub that can do common cases while staying in JavaScript land (i.e. not going to C++). R=jarin@chromium.org BUG=chromium:532524 LOG=n Review URL: https://codereview.chromium.org/1366563002 Cr-Commit-Position: refs/heads/master@{#30890}
-
jkummerow authored
BUG=chromium:527994 LOG=n Review URL: https://codereview.chromium.org/1358393004 Cr-Commit-Position: refs/heads/master@{#30889}
-
machenbach authored
Revert of [heap] Add more tasks for parallel compaction (patchset #11 id:200001 of https://codereview.chromium.org/1354383002/ ) Reason for revert: [Sheriff] May have caused this new flake: http://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/5412 Original issue's description: > [heap] Add more tasks for parallel compaction > > - We now compute the number of parallel compaction tasks, depending on the > evacuation candidate list, the number of cores, and some hard limit. > - Free memory is moved over to compaction tasks (up to some limit) > - Moving over memory is done by dividing the free list of a given space up among > other free lists. Since this is potentially slow we limit the maximum amount > of moved memory. > > BUG=chromium:524425 > LOG=N > > Committed: https://crrev.com/0e842418835eea85886a06cf37052895bc8a17db > Cr-Commit-Position: refs/heads/master@{#30886} TBR=hpayer@chromium.org,mlippautz@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:524425 Review URL: https://codereview.chromium.org/1356363005 Cr-Commit-Position: refs/heads/master@{#30888}
-
jkummerow authored
Whenever a generalization is computed, the inputs must be checked for being cleared, and if they are, the generalization must be Type::Any. Hopefully this fixes Chromium issue 527994 as well. BUG=v8:4325,chromium:527994 LOG=n Review URL: https://codereview.chromium.org/1361103002 Cr-Commit-Position: refs/heads/master@{#30887}
-
mlippautz authored
- We now compute the number of parallel compaction tasks, depending on the evacuation candidate list, the number of cores, and some hard limit. - Free memory is moved over to compaction tasks (up to some limit) - Moving over memory is done by dividing the free list of a given space up among other free lists. Since this is potentially slow we limit the maximum amount of moved memory. BUG=chromium:524425 LOG=N Review URL: https://codereview.chromium.org/1354383002 Cr-Commit-Position: refs/heads/master@{#30886}
-
ishell authored
NOTRY=true Review URL: https://codereview.chromium.org/1364583003 Cr-Commit-Position: refs/heads/master@{#30885}
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1360133002 Cr-Commit-Position: refs/heads/master@{#30884}
-
bmeurer authored
We somehow try to push some stuff on the stack when we detect a stack overflow, that we don't need. Even worse we might access outside the valid stack bounds. Since we don't need this, it's gone. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg R=jarin@chromium.org BUG=chromium:534881 LOG=n Review URL: https://codereview.chromium.org/1360953003 Cr-Commit-Position: refs/heads/master@{#30883}
-
thechargingvolcano authored
FilterFiles function is defined but unused in the code. BUG= R=machenbach@chromium.org Review URL: https://codereview.chromium.org/1364643002 Cr-Commit-Position: refs/heads/master@{#30882}
-
pierre.langlois authored
This patch checks the type of the lhs operand of a floating point comparison, and commutes the operands if it is #0.0. It allows us to optimize a comparison with zero, as the fcmp instruction accepts #0.0 as rhs operand. Code before for "0.0 < 0.123": ------------------------------ fmov d1, xzr ldr d0, pc+96 fcmp d1, d0 b.lo #+0xc Code after: ----------- ldr d0, pc+92 fcmp d0, #0.0 b.gt #+0xc Before this patch, we used unsigned condition codes for floating point comparisons, but the unordered case was not correctly commuted. Review URL: https://codereview.chromium.org/1356283003 Cr-Commit-Position: refs/heads/master@{#30881}
-
jarin authored
(Original CL: https://codereview.chromium.org/1347353003/) Unfortunately, the mips gcc gets confused by arraysize on variadic templated arguments, so we use sizeof... instead. Review URL: https://codereview.chromium.org/1366543003 Cr-Commit-Position: refs/heads/master@{#30880}
-
ishell authored
This CL also renames wrongly named test for v8:4173. BUG=v8:4121 LOG=Y Review URL: https://codereview.chromium.org/1353363002 Cr-Commit-Position: refs/heads/master@{#30879}
-
machenbach authored
Revert of [turbofan] Checking of input counts on node creation (patchset #4 id:60001 of https://codereview.chromium.org/1347353003/ ) Reason for revert: [Sheriff] Breaks mips cross-compile: http://build.chromium.org/p/client.v8/builders/V8%20Mips%20-%20builder/builds/4315 Original issue's description: > [turbofan] Checking of input counts on node creation > > This required fixing bunch of tests with wrong input counts. > > Committed: https://crrev.com/260ec46efd74c45cdc4b156d95086b7de06621ad > Cr-Commit-Position: refs/heads/master@{#30877} TBR=bmeurer@chromium.org,mstarzinger@chromium.org,jarin@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1362783004 Cr-Commit-Position: refs/heads/master@{#30878}
-
jarin authored
This required fixing bunch of tests with wrong input counts. Review URL: https://codereview.chromium.org/1347353003 Cr-Commit-Position: refs/heads/master@{#30877}
-
Benedikt Meurer authored
TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/1363863002 . Cr-Commit-Position: refs/heads/master@{#30876}
-
bmeurer authored
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}
-
bmeurer authored
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}
-
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 10 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}
-