- 28 Apr, 2016 1 commit
-
-
jkummerow authored
This moves __{define,lookup}{Getter,Setter}__ to builtins.cc to free up the JavaScript implementation of DefineOwnProperty for deletion. Review-Url: https://codereview.chromium.org/1904313004 Cr-Commit-Position: refs/heads/master@{#35876}
-
- 29 Mar, 2016 1 commit
-
-
kozyatinskiy authored
This method returns contextDebugId for function. We can't use context_data from FunctionMirror.prototype.script because it can be incorrect when compilation cache is used and one script object was used for JSFunctions in different contexts. BUG=chromium:595206 LOG=Y R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1840713002 Cr-Commit-Position: refs/heads/master@{#35117}
-
- 10 Mar, 2016 1 commit
-
-
rossberg authored
R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org BUG=v8:3956 LOG=Y Review URL: https://codereview.chromium.org/1773653002 Cr-Commit-Position: refs/heads/master@{#34669}
-
- 07 Mar, 2016 1 commit
-
-
mstarzinger authored
The enum in question is (and should) no longer be used outside of the compiler API and hence is being moved back into the Compiler class. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1762323002 Cr-Commit-Position: refs/heads/master@{#34526}
-
- 26 Feb, 2016 3 commits
-
-
rmcilroy authored
Adds support for cpu profiler logging to the interpreter. Modifies the the API to be passed AbstractCode objects instead of Code objects, and adds extra functions to AbstractCode which is required by log.cc and cpu-profiler.cc. The main change in sampler.cc is to determine if a stack frame is an interpreter stack frame, and if so, use the bytecode address as the pc for that frame. This allows sampling of bytecode functions. This requires adding support to SafeStackIterator to determine if a frame is interpreted, which we do by checking the PC against pre-stored addresses for the start and end of interpreter entry builtins. Also removes CodeDeleteEvents which are dead code and haven't been reported for some time. Still to do is tracking source positions which will be done in a followup CL. BUG=v8:4766 LOG=N Review URL: https://codereview.chromium.org/1728593002 Cr-Commit-Position: refs/heads/master@{#34321}
-
bmeurer authored
The %TailCall runtime entry and the %_TailCall intrinsic is not used, and will never be used (because %TailCall doesn't actually do a tail call). We will soon have proper ES6 tail calls, which are correct and properly tested. The %Apply runtime entry is basically a super-slow, less correct version of Reflect.apply, so we can as well just use Reflect.apply, which is exposed to builtins via %reflect_apply. R=ishell@chromium.org Review URL: https://codereview.chromium.org/1739233002 Cr-Commit-Position: refs/heads/master@{#34317}
-
bmeurer authored
The %_Call intrinsic (if supported by the compiler) is lowered directly to the Call builtin and thus throws a TypeError if the target is not callable. The %Call runtime function also eventually calls into the Call builtin, but had an early abort if the target is not a JSReceiver, which is unnecessary and leads to various test failures for Ignition. R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1727833006 Cr-Commit-Position: refs/heads/master@{#34316}
-
- 25 Feb, 2016 1 commit
-
-
mstarzinger authored
This adds explicit setters for the SharedFunctionInfo::function_data field. Such setters are safer because they allow for explicit checking of which values are allowed, and they improve readability because the intended semantics become clear for each call-site. Also fix a cctest case along the way. R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1730853005 Cr-Commit-Position: refs/heads/master@{#34297}
-
- 19 Feb, 2016 1 commit
-
-
mvstanton authored
This is a rework of the instanceof operator to support ES6 semantics (as per section 12.10.4 of the spec: https://tc39.github.io/ecma262/#sec-instanceofoperator). It's behind flag --harmony-instanceof for now, which is turned on for staging. BUG=v8:4447 LOG=N Review URL: https://codereview.chromium.org/1692713005 Cr-Commit-Position: refs/heads/master@{#34170}
-
- 05 Feb, 2016 1 commit
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ ) Reason for revert: Must revert for now due to chromium api natives issues. Original issue's description: > Type Feedback Vector lives in the closure > > (RELAND: the problem before was a missing write barrier for adding the code > entry to the new closure. It's been addressed with a new macro instruction > and test. The only change to this CL is the addition of two calls to > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. > And Benedikt reviewed it as well. > > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org > > BUG= > > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5 > Cr-Commit-Position: refs/heads/master@{#33741} TBR=bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1670813005 Cr-Commit-Position: refs/heads/master@{#33766}
-
- 04 Feb, 2016 1 commit
-
-
mvstanton authored
(RELAND: the problem before was a missing write barrier for adding the code entry to the new closure. It's been addressed with a new macro instruction and test. The only change to this CL is the addition of two calls to __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too. And Benedikt reviewed it as well. TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1668103002 Cr-Commit-Position: refs/heads/master@{#33741}
-
- 03 Feb, 2016 1 commit
-
-
bmeurer authored
R=jarin@chromium.org BUG=chromium:582703 LOG=n Review URL: https://codereview.chromium.org/1664483003 Cr-Commit-Position: refs/heads/master@{#33693}
-
- 01 Feb, 2016 1 commit
-
-
rmcilroy authored
Set the bytecode array correctly in Runtime_SetCode. This fixes issues with building the snapshot with ignition enabled. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1647913002 Cr-Commit-Position: refs/heads/master@{#33638}
-
- 28 Jan, 2016 1 commit
-
-
yangguo authored
This change adds AbstractCode, which can be either Code or BytecodeArray, and adds methods to calculate source position based on that. Also cleans up to use code offsets instead of raw PC where possible, and consistently uses the offset from instruction start (as opposed to code object start). R=rmcilroy@chromium.org, vogelheim@chromium.org BUG=v8:4690 LOG=N Review URL: https://codereview.chromium.org/1618343002 Cr-Commit-Position: refs/heads/master@{#33579}
-
- 27 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ ) Reason for revert: Bug: failing to use write barrier when writing code entry into closure. Original issue's description: > Reland of Type Feedback Vector lives in the closure > > (Fixed a bug found by nosnap builds.) > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > BUG= > > Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1 > Cr-Commit-Position: refs/heads/master@{#33548} TBR=bmeurer@chromium.org,yangguo@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1643533003 Cr-Commit-Position: refs/heads/master@{#33556}
-
mvstanton authored
(Fixed a bug found by nosnap builds.) We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1642613002 Cr-Commit-Position: refs/heads/master@{#33548}
-
- 26 Jan, 2016 2 commits
-
-
mvstanton authored
Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ ) Reason for revert: FAilure on win32 bot, need to investigate webkit failures. Original issue's description: > Type Feedback Vector lives in the closure > > We get less "pollution" of type feedback if we have one vector per native > context, rather than one for the whole system. This CL moves the vector > appropriately. > > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The > vector actually lives in the first slot of the literals array (indeed there is > great commonality between those arrays, they can be thought of as the same > thing). So we make greater effort to ensure there is a valid literals array > after compilation. > > This meant, for performance reasons, that we needed to extend > FastNewClosureStub to support creating closures with literals. And ultimately, > it drove us to move the optimized code map lookup out of FastNewClosureStub > and into the compile lazy builtin. > > The heap change is trivial so I TBR Hannes for it... > > TBR=hpayer@chromium.org > > BUG= > > Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4 > Cr-Commit-Position: refs/heads/master@{#33518} TBR=bmeurer@chromium.org,akos.palfi@imgtec.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1632993003 Cr-Commit-Position: refs/heads/master@{#33520}
-
mvstanton authored
We get less "pollution" of type feedback if we have one vector per native context, rather than one for the whole system. This CL moves the vector appropriately. We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The vector actually lives in the first slot of the literals array (indeed there is great commonality between those arrays, they can be thought of as the same thing). So we make greater effort to ensure there is a valid literals array after compilation. This meant, for performance reasons, that we needed to extend FastNewClosureStub to support creating closures with literals. And ultimately, it drove us to move the optimized code map lookup out of FastNewClosureStub and into the compile lazy builtin. The heap change is trivial so I TBR Hannes for it... TBR=hpayer@chromium.org BUG= Review URL: https://codereview.chromium.org/1563213002 Cr-Commit-Position: refs/heads/master@{#33518}
-
- 08 Jan, 2016 1 commit
-
-
mstarzinger authored
R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1567393003 Cr-Commit-Position: refs/heads/master@{#33177}
-
- 27 Dec, 2015 2 commits
-
-
bmeurer authored
According to the ES2015 specification, bound functions are exotic objects, and thus don't need to be implemented as JSFunctions. So we introduce a new JSBoundFunction type to represent bound functions and make them optimizable. This already improves the performance of calling or constructing bound functions by 10-100x depending on the use case because we avoid the crazy dance between JavaScript and C++ that was implemented in v8natives.js previously. There's still room for improvement in the performance of actually creating bound functions, which is also relevant in practice, but we already have a plan how to accomplish that later. The mips/mips64 ports were contributed by akos.palfi@imgtec.com. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=chromium:535408, chromium:571299, v8:4629 LOG=n Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2 Cr-Commit-Position: refs/heads/master@{#33042} Review URL: https://codereview.chromium.org/1542963002 Cr-Commit-Position: refs/heads/master@{#33044}
-
bmeurer authored
Revert of [runtime] Introduce dedicated JSBoundFunction to represent bound functions. (patchset #14 id:260001 of https://codereview.chromium.org/1542963002/ ) Reason for revert: Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind Original issue's description: > [runtime] Introduce dedicated JSBoundFunction to represent bound functions. > > According to the ES2015 specification, bound functions are exotic > objects, and thus don't need to be implemented as JSFunctions. So > we introduce a new JSBoundFunction type to represent bound functions > and make them optimizable. This already improves the performance of > calling or constructing bound functions by 10-100x depending on the > use case because we avoid the crazy dance between JavaScript and C++ > that was implemented in v8natives.js previously. > > There's still room for improvement in the performance of actually > creating bound functions, which is also relevant in practice, but > we already have a plan how to accomplish that later. > > The mips/mips64 ports were contributed by akos.palfi@imgtec.com. > > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel > BUG=chromium:535408, chromium:571299, v8:4629 > LOG=n > > Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2 > Cr-Commit-Position: refs/heads/master@{#33042} TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:535408, chromium:571299, v8:4629 Review URL: https://codereview.chromium.org/1552473002 Cr-Commit-Position: refs/heads/master@{#33043}
-
- 26 Dec, 2015 1 commit
-
-
bmeurer authored
According to the ES2015 specification, bound functions are exotic objects, and thus don't need to be implemented as JSFunctions. So we introduce a new JSBoundFunction type to represent bound functions and make them optimizable. This already improves the performance of calling or constructing bound functions by 10-100x depending on the use case because we avoid the crazy dance between JavaScript and C++ that was implemented in v8natives.js previously. There's still room for improvement in the performance of actually creating bound functions, which is also relevant in practice, but we already have a plan how to accomplish that later. The mips/mips64 ports were contributed by akos.palfi@imgtec.com. CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=chromium:535408, chromium:571299, v8:4629 LOG=n Review URL: https://codereview.chromium.org/1542963002 Cr-Commit-Position: refs/heads/master@{#33042}
-
- 22 Dec, 2015 2 commits
-
-
bmeurer authored
These constructors always go through C++ at least twice anyway, so there's not really a point in trying to implement them in JavaScript. R=yangguo@chromium.org BUG=chromium:535408 LOG=n Review URL: https://codereview.chromium.org/1548623002 Cr-Commit-Position: refs/heads/master@{#33012}
-
bmeurer authored
There's actually no point trying to do Function.prototype.toString in JavaScript, as it always calls into C++ at least once, so it only complicates things (esp. once we start optimizing bound functions). Drive-by-fix: Rename FunctionApply and FunctionCall builtins to also reflect the fact that these are builtins in the Function.prototype and not on Function itself. TBR=hpayer@chromium.org R=yangguo@chromium.org BUG=chromium:535408 LOG=n Review URL: https://codereview.chromium.org/1540953004 Cr-Commit-Position: refs/heads/master@{#32996}
-
- 17 Dec, 2015 1 commit
-
-
neis authored
- Before getting the length property, we must check for it using [[GetOwnProperty]]. Also, if the obtained length is a number, we must properly convert it to an integer. - In order to get the prototype we must use [[GetPrototypeOf]], and do so before checking the length. R=cbruni@chromium.org, jkummerow@chromium.org BUG=v8:1543 LOG=n Review URL: https://codereview.chromium.org/1530893002 Cr-Commit-Position: refs/heads/master@{#32934}
-
- 10 Dec, 2015 1 commit
-
-
ishell authored
Function subclasses did not have function properties installed (name, prototype, etc.). Now when an instance of a Function subclass is created it gets initial map that corresponds to the language mode of the function body. The language mode dependent maps are cached as special transitions on initial map of the subclass constructor. BUG=v8:4597, v8:3101, v8:3330 LOG=Y Review URL: https://codereview.chromium.org/1510753005 Cr-Commit-Position: refs/heads/master@{#32764}
-
- 01 Dec, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1479233002 Cr-Commit-Position: refs/heads/master@{#32470}
-
- 27 Nov, 2015 1 commit
-
-
verwaest authored
This makes sure that proxy + Function/Array works Makes sure that new.target can be a generator Makes sure that if new.target is not a subclass, but does not have a prototype, that we'll get that same prototype back the next time we look at new.target.prototype. BUG=v8:1543, v8:3330, v8:3931 LOG=n Review URL: https://codereview.chromium.org/1484473002 Cr-Commit-Position: refs/heads/master@{#32382}
-
- 25 Nov, 2015 1 commit
-
-
mstarzinger authored
This passes the new.target value in a register instead of through a side-channel via the construct stub. The interpreter entry trampoline stores this value in a bytecode register so that it can be accessed directly by the interpreter. The size of the interpreter stack frame hence grows by one slot. R=oth@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1469313002 Cr-Commit-Position: refs/heads/master@{#32264}
-
- 24 Nov, 2015 2 commits
-
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1467473002 Cr-Commit-Position: refs/heads/master@{#32223}
-
mstarzinger authored
This passes the new.target value in a register instead of through a side-channel via the construct stub. Note that only TurboFan code uses the register value so far, but unoptimized code will be switched soon. R=bmeurer@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1460503008 Cr-Commit-Position: refs/heads/master@{#32203}
-
- 19 Nov, 2015 1 commit
-
-
mvstanton authored
This simplifies follow-on changes to the FastNewClosureStub. BUG= Review URL: https://codereview.chromium.org/1433923002 Cr-Commit-Position: refs/heads/master@{#32123}
-
- 17 Nov, 2015 1 commit
-
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1442643009 Cr-Commit-Position: refs/heads/master@{#32023}
-
- 13 Nov, 2015 2 commits
-
-
danno authored
* Limit triggering of tail calls to explicit use of a new inline runtime function %_TailCall. %_TailCall works just like %_Call except for using tail-calling mechanics (currently only in TF). * Remove hack that recognized some specific usages of %_Call and converted them into tail calls. * Support tail calls for all calls where the number of callee stack parameters is less than or equal to the number of caller stack parameters. * Use the gap resolver to swizzle parameters and registers to tail calls. BUG=v8:4076 LOG=n Review URL: https://codereview.chromium.org/1439613003 Cr-Commit-Position: refs/heads/master@{#31987}
-
mstarzinger authored
This aligns the naming of "new target" with the spec text throughout TurboFan and the stack frame walker. The goal is to avoid unnecessary confusion for people familiar with the spec. R=verwaest@chromium.org Review URL: https://codereview.chromium.org/1442643002 Cr-Commit-Position: refs/heads/master@{#31978}
-
- 12 Nov, 2015 1 commit
-
-
mstarzinger authored
This implements a first version of support for constructor call inlining in the inlining machinery. For now we can only inline calls where the actual constructor and the original constructor coincide (i.e. no super constructor calls). Note that the target of a super constructor call is loaded with a runtime call, so there is no way for it to be constant promoted at the moment. R=bmeurer@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1435873002 Cr-Commit-Position: refs/heads/master@{#31954}
-
- 05 Nov, 2015 1 commit
-
-
bmeurer authored
The %_CallFunction doesn't implement the call sequence properly, it doesn't do the receiver wrapping, nor does it check for classConstructor. Also the eager deoptimization for %_CallFunction was seriously b0rked (we must have been lucky with TurboFan so far). R=yangguo@chromium.org BUG=v8:4413 LOG=n Review URL: https://codereview.chromium.org/1419813010 Cr-Commit-Position: refs/heads/master@{#31821}
-
- 04 Nov, 2015 3 commits
-
-
mstarzinger authored
This removes several methods from JSFunction that just delegate to SharedFunctionInfo. These methods are especially dangerous when they hide the fact that they potentially affect all function instances deriving from the same underlying SharedFunctionInfo. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1417213005 Cr-Commit-Position: refs/heads/master@{#31792}
-
cbruni authored
The current implementation of classes throws the TypeError at the wrong point, after activating a new context when directly calling a class constructor. According to the spec, the TypeError has to be thrown in the caller context. LOG=N BUG=v8:4428 Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90 Cr-Commit-Position: refs/heads/master@{#31786} Review URL: https://codereview.chromium.org/1418623007 Cr-Commit-Position: refs/heads/master@{#31790}
-
cbruni authored
Revert of [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor. (patchset #20 id:370001 of https://codereview.chromium.org/1418623007/ ) Reason for revert: failing build bot Original issue's description: > [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor. > > The current implementation of classes throws the TypeError at the wrong > point, after activating a new context when directly calling a class > constructor. According to the spec, the TypeError has to be thrown > in the caller context. > > LOG=N > BUG=v8:4428 > > Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90 > Cr-Commit-Position: refs/heads/master@{#31786} TBR=bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4428 Review URL: https://codereview.chromium.org/1415783006 Cr-Commit-Position: refs/heads/master@{#31787}
-