- 27 Jan, 2016 1 commit
-
-
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 4 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}
-
rmcilroy authored
Rename IntepreterExceptionEntryHandler builtin to InterpreterEnterBytecodeDispatch and use it as the return address when building interpreter frames during deopt. This ensures that we restart execution of the outer frame at the correct bytecode. BUG=v8:4280,v8:4678 LOG=N Review URL: https://codereview.chromium.org/1633633002 Cr-Commit-Position: refs/heads/master@{#33512}
-
ishell authored
This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan. When debugger is active tail calls are disabled. Tail calling can be enabled by --harmony-tailcalls flag. BUG=v8:4698 LOG=Y TBR=rossberg@chromium.org Review URL: https://codereview.chromium.org/1609893003 Cr-Commit-Position: refs/heads/master@{#33509}
-
- 23 Jan, 2016 1 commit
-
-
rmcilroy authored
Change the interpreter to always store the current context in the frame's context slot instead of the function context. This makes it possible to restore the correct context during deopt. BUG=v8:4678,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1604923002 Cr-Commit-Position: refs/heads/master@{#33477}
-
- 22 Jan, 2016 1 commit
-
-
mstarzinger authored
This fixes the broken return address when the exception handler within interpreted bytecode is being entered via stack unwinding. The address in question will never actually be taken, but our stack walker uses this address to determine whether a frame is interpreted. R=rmcilroy@chromium.org TEST=cctest/test-interpreter/InterpreterTryCatch BUG=v8:4674 LOG=n Review URL: https://codereview.chromium.org/1615063002 Cr-Commit-Position: refs/heads/master@{#33463}
-
- 20 Jan, 2016 1 commit
-
-
mstarzinger authored
This implements a first prototype of stack unwinding for interpreted frames. The unwinding machinery performs a range-based lookup in the given handler table and potentially continues dispatching at the handler offset. Note that this does not yet correctly restore the context to the correct value when the handler is being entered. R=rmcilroy@chromium.org,oth@chromium.org BUG=v8:4674 LOG=n Review URL: https://codereview.chromium.org/1605633003 Cr-Commit-Position: refs/heads/master@{#33414}
-
- 15 Jan, 2016 1 commit
-
-
cbruni authored
When derived constructors return a non-object (or not undefined) we currently throw an exception directly in the callee context. This was achieved by desugaring the return statement for derived classes. To be spec compliamnt a separate ConstructStubForDerived is introduced. Instead of trowing directly, the desugared return statement inside a derived constructor only returns an integer to indicate an incompatible result. BUG=v8:4509 LOG=n Review URL: https://codereview.chromium.org/1593553002 Cr-Commit-Position: refs/heads/master@{#33336}
-
- 14 Jan, 2016 2 commits
-
-
jkummerow authored
When reserving a stack slot for the receiver, push an Immediate(0) rather than a register that contains an untagged integer. All other platforms push zero already. Review URL: https://codereview.chromium.org/1585183002 Cr-Commit-Position: refs/heads/master@{#33299}
-
epertoso authored
CompatibleReceiverCheck used by the HandleFastApiCall builtin was terminating with failure upon encountering a hidden prototype. It should actually stop iterating on the first non-hidden prototype. BUG= Review URL: https://codereview.chromium.org/1576423003 Cr-Commit-Position: refs/heads/master@{#33294}
-
- 13 Jan, 2016 2 commits
-
-
bmeurer authored
Also migrate the Number constructor to a native builtin, using the same mechanism already used by the String constructor. Otherwise just parsing and compiling the Number constructor to optimized code already eats 2ms on desktop for no good reason, and the resulting optimized code is not even close to awesome. Drive-by-fix: Use correct context for the [[Construct]] case of the String constructor as well, and share some code with it. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1573243009 Cr-Commit-Position: refs/heads/master@{#33265}
-
bmeurer authored
The API functions are always in sloppy mode, so receiver is always a JSReceiver once the actual call trampoline runs, no need to check again in various places. R=verwaest@chromium.org Review URL: https://codereview.chromium.org/1575973006 Cr-Commit-Position: refs/heads/master@{#33258}
-
- 08 Jan, 2016 1 commit
-
-
bmeurer authored
There's no reason to have JavaScript wrappers for those accessors, since the meat is already in hand-written native code (via %_DateField). First step now to put them into native builtins. Next step will be to completely remove %_DateField. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1567353002 Cr-Commit-Position: refs/heads/master@{#33172}
-
- 04 Jan, 2016 1 commit
-
-
rmcilroy authored
Fix stack push issues on non-x64 platforms for InterpreterNotifyDeoptimized builtins. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1553123002 Cr-Commit-Position: refs/heads/master@{#33088}
-
- 30 Dec, 2015 1 commit
-
-
cbruni authored
counts specified in runtime.h. In the vast majority of the cases when we call into the runtime we use the default number of arguments. Hence, there is not need to specify it again. This CL also removes TailCallExternalReference as there were no users. BUG= Review URL: https://codereview.chromium.org/1553703002 Cr-Commit-Position: refs/heads/master@{#33066}
-
- 29 Dec, 2015 1 commit
-
-
cbruni authored
JumpToExternalReference ignored the passed-in result_size argument, which defaulted to 1. This change updates all users to not use a result_size. BUG= Review URL: https://codereview.chromium.org/1550923002 Cr-Commit-Position: refs/heads/master@{#33059}
-
- 28 Dec, 2015 1 commit
-
-
bmeurer authored
When calling into C++ for a ConstructStub, we need to enter the target context manually currently, which seems to be too fragile and easy to forget. So instead of doing that manually, we just always enter the correct context in the trampoline. Drive-by-fix: Trivial cleanups for some builtins. R=cbruni@chromium.org Review URL: https://codereview.chromium.org/1551473002 Cr-Commit-Position: refs/heads/master@{#33051}
-
- 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 1 commit
-
-
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}
-
- 18 Dec, 2015 1 commit
-
-
rmcilroy authored
Adds support for generating deoptimization translations for interpreter stack frames, and building interpreter frames for these translations when a function deopts. Also adds builtins for InterpreterNotifyDeoptimized which resume the function's continuation at the correct point in the interpreter after deopt. MIPS patch contributed by balazs.kilvady@igmtec.com BUG=v8:4280 LOG=N TEST=test-deoptimization.cc with --ignition and --turbo Review URL: https://codereview.chromium.org/1528913003 Cr-Commit-Position: refs/heads/master@{#32971}
-
- 17 Dec, 2015 3 commits
-
-
Benedikt Meurer authored
Introduce a new Apply builtin that forms a correct and optimizable foundation for the Function.prototype.apply, Reflect.construct and Reflect.apply builtins (which properly does the PrepareForTailCall as required by the ES2015 spec). The new Apply builtin avoids going to the runtime if it is safe to just access the backing store elements of the argArray, i.e. if you pass a JSArray with no holes, or an unmapped, unmodified sloppy or strict arguments object. mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux64_tsan_rel BUG=v8:4413, v8:4430 LOG=n R=yangguo@chromium.org Committed: https://chromium.googlesource.com/v8/v8/+/e4d2538911f6cb4b626830ccbb3c1f5746542697 Review URL: https://codereview.chromium.org/1523753002 . Cr-Commit-Position: refs/heads/master@{#32929}
-
Benedikt Meurer authored
Revert of [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply. (patchset #5 id:80001 of https://codereview.chromium.org/1523753002/ ) Reason for revert: Breaks TSAN somewhow: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7000 Original issue's description: > [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply. > > Introduce a new Apply builtin that forms a correct and optimizable > foundation for the Function.prototype.apply, Reflect.construct and > Reflect.apply builtins (which properly does the PrepareForTailCall > as required by the ES2015 spec). > > The new Apply builtin avoids going to the runtime if it is safe to > just access the backing store elements of the argArray, i.e. if you > pass a JSArray with no holes, or an unmapped, unmodified sloppy or > strict arguments object. > > mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com> > > CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel > BUG=v8:4413, v8:4430 > LOG=n > R=yangguo@chromium.org > > Committed: https://chromium.googlesource.com/v8/v8/+/e4d2538911f6cb4b626830ccbb3c1f5746542697 TBR=yangguo@chromium.org,paul.lind@imgtec.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4413, v8:4430 Review URL: https://codereview.chromium.org/1533803002 . Cr-Commit-Position: refs/heads/master@{#32928}
-
Benedikt Meurer authored
Introduce a new Apply builtin that forms a correct and optimizable foundation for the Function.prototype.apply, Reflect.construct and Reflect.apply builtins (which properly does the PrepareForTailCall as required by the ES2015 spec). The new Apply builtin avoids going to the runtime if it is safe to just access the backing store elements of the argArray, i.e. if you pass a JSArray with no holes, or an unmapped, unmodified sloppy or strict arguments object. mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel BUG=v8:4413, v8:4430 LOG=n R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1523753002 . Cr-Commit-Position: refs/heads/master@{#32927}
-
- 16 Dec, 2015 1 commit
-
-
rmcilroy authored
Adds a slot for the bytecode offset to interpreter stack frames and saves it on calls, and restores after calls. Also fixes RawMachineAssembler::Return() to call MergeControlToEnd. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1512543002 Cr-Commit-Position: refs/heads/master@{#32906}
-
- 09 Dec, 2015 2 commits
-
-
cbruni authored
LOG=N BUG=v8:1543 Review URL: https://codereview.chromium.org/1509603005 Cr-Commit-Position: refs/heads/master@{#32718}
-
ishell authored
Review URL: https://codereview.chromium.org/1506683004 Cr-Commit-Position: refs/heads/master@{#32698}
-
- 08 Dec, 2015 1 commit
-
-
cbruni authored
BUG=v8:1543 LOG=N Review URL: https://codereview.chromium.org/1499593003 Cr-Commit-Position: refs/heads/master@{#32675}
-
- 04 Dec, 2015 1 commit
-
-
cbruni authored
BUG=v8:1543 LOG=N Review URL: https://codereview.chromium.org/1496503002 Cr-Commit-Position: refs/heads/master@{#32616}
-
- 03 Dec, 2015 2 commits
-
-
mstarzinger authored
This drops the specific slot containing the new.target value from our construct stub frames. This side-channel has been deprecated and will no longer be accessed by any consumers. R=verwaest@chromium.org Review URL: https://codereview.chromium.org/1489353004 Cr-Commit-Position: refs/heads/master@{#32550}
-
ishell authored
It didn't support subclassing case at all and in non-subclassing case the runtime allocation didn't do the slack tracking step. BUG=chromium:563339 LOG=Y Review URL: https://codereview.chromium.org/1488023002 Cr-Commit-Position: refs/heads/master@{#32547}
-
- 02 Dec, 2015 2 commits
-
-
bmeurer authored
Allow to pass new.target (in addition to target) to C++ builtins, and remove some obsolete/dangerous code from the C++ builtins. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1491883002 Cr-Commit-Position: refs/heads/master@{#32505}
-
bmeurer authored
Sanitize ConstructStub handling and add a test case to ensure that the Symbol constructor is using the correct context. R=jarin@chromium.org BUG=v8:4413 LOG=n Review URL: https://codereview.chromium.org/1489323002 Cr-Commit-Position: refs/heads/master@{#32491}
-
- 30 Nov, 2015 2 commits
-
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1483933002 Cr-Commit-Position: refs/heads/master@{#32403}
-
neis authored
Use {FIRST,LAST}_JS_RECEIVER_TYPE instead. R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1486563002 Cr-Commit-Position: refs/heads/master@{#32393}
-
- 27 Nov, 2015 3 commits
-
-
bmeurer authored
Previously all contexts had a link to the global object, but what is required in most cases (except for the global load, store and delete case) is the native context. This also removes the second dummy global object that was still linked to every native context. We will add a different mechanism to ensure that builtins do not pollute the actual global object during bootstrapping. Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel R=yangguo@chromium.org,mstarzinger@chromium.org Committed: https://crrev.com/d290f204938295bfecc5c8e645ccfcff6e80ddb8 Cr-Commit-Position: refs/heads/master@{#32375} Review URL: https://codereview.chromium.org/1480003002 Cr-Commit-Position: refs/heads/master@{#32381}
-
machenbach authored
Revert of [runtime] Replace global object link with native context link in all contexts. (patchset #3 id:40001 of https://codereview.chromium.org/1480003002/ ) Reason for revert: [Sheriff] Breaks: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/5472 Original issue's description: > [runtime] Replace global object link with native context link in all contexts. > > Previously all contexts had a link to the global object, but what is > required in most cases (except for the global load, store and delete > case) is the native context. > > This also removes the second dummy global object that was still linked > to every native context. We will add a different mechanism to ensure > that builtins do not pollute the actual global object during > bootstrapping. > > Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. > > R=yangguo@chromium.org > > Committed: https://crrev.com/d290f204938295bfecc5c8e645ccfcff6e80ddb8 > Cr-Commit-Position: refs/heads/master@{#32375} TBR=yangguo@chromium.org,mstarzinger@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1478303002 Cr-Commit-Position: refs/heads/master@{#32377}
-
bmeurer authored
Previously all contexts had a link to the global object, but what is required in most cases (except for the global load, store and delete case) is the native context. This also removes the second dummy global object that was still linked to every native context. We will add a different mechanism to ensure that builtins do not pollute the actual global object during bootstrapping. Drive-by-fix: Unify some MacroAssembler magic and drop obsolete stuff. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1480003002 Cr-Commit-Position: refs/heads/master@{#32375}
-