- 23 May, 2019 2 commits
-
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
Yang Guo authored
Bug: v8:9247 Change-Id: I0023200c54fa6499ae4e2cf5e4c89407cc35f187 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624218Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61762}
-
- 22 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I79e0553e8a0d6dac2aa16b94a6c0e05b6ccde4a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621934 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61725}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 15 May, 2019 1 commit
-
-
Tobias Tebbi authored
With very few exceptions, this verifies all skipped write-barriers in CSA and Torque, showing that the MemoryOptimizer together with some type information on the stored value are enough to avoid unsafe skipped write-barriers. Changes to CSA: SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the MemoryOptimizer by default. Type information about the stored values (TNode<Smi>) is exploited to safely skip write barriers for stored Smi values. In some cases, the code is re-structured to make it easier to consume for the MemoryOptimizer (manual branch and load elimination). Changes to the MemoryOptimizer: Improve the MemoryOptimizer to remove write barriers: - When the store happens to a CSA-generated InnerAllocate, by ignoring Bitcasts and additions. - When the stored value is the HeapConstant of an immortal immovable root. - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned). - Fast C-calls are treated as non-allocating. - Runtime calls can be white-listed as non-allocating. Remaining missing cases: - C++-style iterator loops with inner pointers. - Inner allocates that are reloaded from a field where they were just stored (for example an elements backing store). Load elimination would fix that. - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole). We could handle that in Torque. - Double-aligned allocations, which are not lowered in the MemoryOptimizer but in CSA. Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this can be handled by overload resolution (in Torque and C++). Reland Change: Support pointer compression operands. R=jarin@chromium.org TBR=mvstanton@chromium.org Bug: v8:7793 Change-Id: I84e1831eb6bf9be14f36db3f8b485ee4fab6b22e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612904 Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61522}
-
- 13 May, 2019 1 commit
-
-
Joyee Cheung authored
Added null check when printing the brand with --print-ast. Bug: chromium:961507, chromium:961508 Original change's description: > [class] implement private method declarations > > This patch implements the declarations of private methods, the access > of private methods would be left to a future patch. > When a private methods declaration is encountered, we now: > > - Create a brand symbol during class evaluation and store it in the > context. > - Create the closures for the private methods > - Load the brand from the context and store it in the instance in the > constructor. > > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit# > > Bug: v8:8330 > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708 > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61387} Change-Id: I3bf465f70c27914c9ec19f3f59ae018b28c9a866 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605521 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61459}
-
- 10 May, 2019 1 commit
-
-
Ross McIlroy authored
This reverts commit b9191bd3. Reason for revert: Clusterfuzz bugs BUG=chromium:961507,chromium:961508 Original change's description: > [class] implement private method declarations > > This patch implements the declarations of private methods, the access > of private methods would be left to a future patch. > When a private methods declaration is encountered, we now: > > - Create a brand symbol during class evaluation and store it in the > context. > - Create the closures for the private methods > - Load the brand from the context and store it in the instance in the > constructor. > > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit# > > Bug: v8:8330 > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708 > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61387} TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8330 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61406}
-
- 09 May, 2019 1 commit
-
-
Joyee Cheung authored
This patch implements the declarations of private methods, the access of private methods would be left to a future patch. When a private methods declaration is encountered, we now: - Create a brand symbol during class evaluation and store it in the context. - Create the closures for the private methods - Load the brand from the context and store it in the instance in the constructor. Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit# Bug: v8:8330 Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#61387}
-
- 26 Apr, 2019 1 commit
-
-
Ross McIlroy authored
This reverts commit da7322c0. Reason for revert: Breaking the pointer compression bots, e.g.: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047 Original change's description: > [csa] verify skipped write-barriers in MemoryOptimizer > > With very few exceptions, this verifies all skipped write-barriers in > CSA and Torque, showing that the MemoryOptimizer together with some > type information on the stored value are enough to avoid unsafe skipped > write-barriers. > > Changes to CSA: > SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the > MemoryOptimizer by default. > Type information about the stored values (TNode<Smi>) is exploited to > safely skip write barriers for stored Smi values. > In some cases, the code is re-structured to make it easier to consume > for the MemoryOptimizer (manual branch and load elimination). > > Changes to the MemoryOptimizer: > Improve the MemoryOptimizer to remove write barriers: > - When the store happens to a CSA-generated InnerAllocate, by ignoring > Bitcasts and additions. > - When the stored value is the HeapConstant of an immortal immovable root. > - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned). > - Fast C-calls are treated as non-allocating. > - Runtime calls can be white-listed as non-allocating. > > Remaining missing cases: > - C++-style iterator loops with inner pointers. > - Inner allocates that are reloaded from a field where they were just stored > (for example an elements backing store). Load elimination would fix that. > - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole). > We could handle that in Torque. > - Double-aligned allocations, which are not lowered in the MemoryOptimizer > but in CSA. > > Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this > can be handled by overload resolution (in Torque and C++). > > R=jarin@chromium.org > TBR=mvstanton@chromium.org > > Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61016} TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61038}
-
- 25 Apr, 2019 1 commit
-
-
Tobias Tebbi authored
With very few exceptions, this verifies all skipped write-barriers in CSA and Torque, showing that the MemoryOptimizer together with some type information on the stored value are enough to avoid unsafe skipped write-barriers. Changes to CSA: SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the MemoryOptimizer by default. Type information about the stored values (TNode<Smi>) is exploited to safely skip write barriers for stored Smi values. In some cases, the code is re-structured to make it easier to consume for the MemoryOptimizer (manual branch and load elimination). Changes to the MemoryOptimizer: Improve the MemoryOptimizer to remove write barriers: - When the store happens to a CSA-generated InnerAllocate, by ignoring Bitcasts and additions. - When the stored value is the HeapConstant of an immortal immovable root. - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned). - Fast C-calls are treated as non-allocating. - Runtime calls can be white-listed as non-allocating. Remaining missing cases: - C++-style iterator loops with inner pointers. - Inner allocates that are reloaded from a field where they were just stored (for example an elements backing store). Load elimination would fix that. - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole). We could handle that in Torque. - Double-aligned allocations, which are not lowered in the MemoryOptimizer but in CSA. Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this can be handled by overload resolution (in Torque and C++). R=jarin@chromium.org TBR=mvstanton@chromium.org Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61016}
-
- 02 Feb, 2019 1 commit
-
-
Suraj Sharma authored
The program: foo; let foo = 5; …now produces: ReferenceError: Cannot access 'foo' before initialization …instead of: ReferenceError: foo is not defined Bug: v8:6513, v8:6951 Change-Id: I6c372626734570d5abeb1d0196b814dde02b9e3e Reviewed-on: https://chromium-review.googlesource.com/c/1441151Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Commit-Queue: Suraj Sharma <surshar@microsoft.com> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#59307}
-
- 18 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
instead of Object* (which is deprecated) or ObjectPtr (which is unsuitable for cases where we need to control the ABI exactly). Callers in generated code expect a plain tagged value, so return precisely that. Same for C++ Builtins. Bug: v8:3770 Change-Id: Id12f0d9830f7caf2a16aa973b8297f70d65241f5 Reviewed-on: https://chromium-review.googlesource.com/c/1382466Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58334}
-
- 07 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
as part of the ongoing quest to get rid of Object*/Object** entirely. Design overview: https://goo.gl/Ph4CGz Bug: v8:3770 Change-Id: Ie79a461a61203ea5a6efcd7b2a31bff1834169dd Reviewed-on: https://chromium-review.googlesource.com/c/1316607 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#57306}
-
- 06 Nov, 2018 1 commit
-
-
Joyee Cheung authored
Rename variables and flag names so that the classes can be reused by private methods implementation. In particular: Rename "fields" to "members" in the initializer so that we can initialize both fields and private methods/accessors there, for example: instance_fields_initializer -> instance_members_initializer InitializeClassFieldsStatement -> InitializeClassMembersStatement Rename "private field" to "private name" for the private symbols used to implement private fields so that we can use them to store private methods/accessors later as well, for example: private_field_name_var -> private_name_var NewPrivateFieldSymbol -> NewPrivateNameSymbol The follow-on is in https://chromium-review.googlesource.com/c/v8/v8/+/1301018 The design doc is in https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing Bug: v8:8330 Change-Id: I1cdca8def711da879b6e4d67c5ff0a5a4a36abbe Reviewed-on: https://chromium-review.googlesource.com/c/1312597Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#57289}
-
- 10 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
-
- 08 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This change adds predicates to check whether a given JavaScript operator needs the "current context" or if any surrounding context (including the "native context") does it. For example JSAdd doesn't ever need the current context, but actually only the native context. In the BytecodeGraphBuilder we use this predicate to check whether a given operator needs the current context, and if not, we just pass in the native context. Doing so we improve the performance on the benchmarks given in the tracking bug significantly, and go from something around arrayMap: 476 ms. arrayFilter: 312 ms. arrayEvery: 241 ms. arraySome: 152 ms. to arrayMap: 377 ms. arrayFilter: 296 ms. arrayEvery: 191 ms. arraySome: 91 ms. which is an up to 40% improvement. So for idiomatic modern JavaScript which uses higher order functions quite a lot, not just the builtins provided by the JSVM, this is going to improve peak performance noticably. This also makes it possible to completely eliminate all the allocations in the aliased sloppy arguments example ```js function foo(a) { return arguments.length; } ``` concretely we don't allocate the function context anymore and we also don't allocate the arguments object anymore (the JSStackCheck was the reason why we did this in the past, because it was holding on to the current context, which also kept the allocation for the arguments alive). Bug: v8:6200, v8:8060 Change-Id: I1db56d00d6b510ce6337608c0fff16af96e95eef Design-Document: bit.ly/v8-turbofan-context-sensitive-js-operators Reviewed-on: https://chromium-review.googlesource.com/c/1267176Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56441}
-
- 05 Oct, 2018 1 commit
-
-
Peter Marshall authored
For each intrinsic/runtime function we define in runtime.h, an inline version is automatically declared. We only ever use 24 of the inline functions. Even though we don't call the other ones, macro magic means they still take up space by existing in various arrays and tables like kIntrinsicFunctions. They also create code in switch statements. Some drive-by cleanups: - Remove the switch in NameForRuntimeId() and just use the table of runtime functions to lookup the name directly. - Remove tests for IsFunction, ClassOf and StringAdd intrinsics as they are the last users of the inline versions of these. - Remove the MaxSmi inline version as it is only used in tests. Saves 64 KiB binary size. Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5 Reviewed-on: https://chromium-review.googlesource.com/c/1261939 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#56412}
-
- 05 Sep, 2018 1 commit
-
-
Hai Dang authored
This is a reland of 1c48d52b. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
-
- 31 Aug, 2018 1 commit
-
-
Georg Neis authored
This reverts commit 1c48d52b. Reason for revert: Clusterfuzz found something. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
-
- 30 Aug, 2018 1 commit
-
-
Hai Dang authored
This CL improves the performance of creating [...a, b] or [...a]. If the array literal has a leading spread, this CL emits the bytecode [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable is implemented by [IterableToListDefault] builtin to create the initial array for the leading spread. IterableToListDefault has a fast path to clone efficiently if the spread is an actual array. The bytecode generated is now shorter. Bytecode generation is refactored into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit from this optimization also. For now, turbofan also lowers the bytecode to the builtin. The idiomatic use of [...a] to clone the array a now performs better than a simple for-loop, but still does not match the performance of slice. Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Hai Dang <dhai@google.com> Cr-Commit-Position: refs/heads/master@{#55520}
-
- 17 Aug, 2018 1 commit
-
-
Sigurd Schneider authored
This reduced the number of targets depending on assembler.h from ~900 to ~350. Bug: v8:8054 Change-Id: I74ae2ce7a4b27791d0ee25542ee0b2175bedf5f7 Reviewed-on: https://chromium-review.googlesource.com/1174534 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55188}
-
- 25 Apr, 2018 1 commit
-
-
Andreas Haas authored
I missed one required change which was hidden behind an #if. The fix is in the diff between Patch 1 and Patch 3. Original message: In this CL I remove the isolate from signatures of ExternalReference accessor functions where the isolate is not used. The uses of the isolate were already removed in previous CLs. Changes: * I split the ExternalReference list in external-reference.h into those which need the isolate for initialization and those which do not. * I removed the public constructors and replaced them by ExternalReference::Create(). The reason is to separate external creation more clearly from internal creation, because externally created ExternalReferences sometimes need redirection, whereas internally created ExternalReferences are just stored as they are. In addition, by removing the isolate from the signature of the public constructors, they suddenly exactly matched the interal constructor. * Replace all uses of the public constructors with ExternalReference::Create(). * Remove the isolate from all call sites where necessary. This is a step towards making WebAssembly compilation independent of the isolate. R=mstarzinger@chromium.org Bug: v8:7570 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057 Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52777}
-
- 24 Apr, 2018 2 commits
-
-
Andreas Haas authored
This reverts commit 44ea425a. Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575 Original change's description: > [refactoring] Remove the isolate from signatures of ExternalReferences > > In this CL I remove the isolate from signatures of ExternalReference > accessor functions where the isolate is not used. The uses of the > isolate were already removed in previous CLs. > > Changes: > * I split the ExternalReference list in external-reference.h into > those which need the isolate for initialization and those which do not. > > * I removed the public constructors and replaced them by > ExternalReference::Create(). The reason is to separate external > creation more clearly from internal creation, because externally > created ExternalReferences sometimes need redirection, whereas > internally created ExternalReferences are just stored as they are. > In addition, by removing the isolate from the signature of the > public constructors, they suddenly exactly matched the interal > constructor. > > * Replace all uses of the public constructors with > ExternalReference::Create(). > > * Remove the isolate from all call sites where necessary. > > > This is a step towards making WebAssembly compilation independent of > the isolate. > > Bug: v8:7570 > R=mstarzinger@chromium.org > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da > Reviewed-on: https://chromium-review.googlesource.com/1018982 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52768} TBR=mstarzinger@chromium.org,ahaas@chromium.org Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7570 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52769}
-
Andreas Haas authored
In this CL I remove the isolate from signatures of ExternalReference accessor functions where the isolate is not used. The uses of the isolate were already removed in previous CLs. Changes: * I split the ExternalReference list in external-reference.h into those which need the isolate for initialization and those which do not. * I removed the public constructors and replaced them by ExternalReference::Create(). The reason is to separate external creation more clearly from internal creation, because externally created ExternalReferences sometimes need redirection, whereas internally created ExternalReferences are just stored as they are. In addition, by removing the isolate from the signature of the public constructors, they suddenly exactly matched the interal constructor. * Replace all uses of the public constructors with ExternalReference::Create(). * Remove the isolate from all call sites where necessary. This is a step towards making WebAssembly compilation independent of the isolate. Bug: v8:7570 R=mstarzinger@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da Reviewed-on: https://chromium-review.googlesource.com/1018982 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52768}
-
- 17 Apr, 2018 1 commit
-
-
Andreas Haas authored
In a recent CL (https://crrev.com/c/1012039) I removed the only valid use case of {external_reference_redirector}. In this CL I remove the remaining uses, which are more or less checks if there is a simulator or not. R=mstarzinger@chromium.org Change-Id: I96203b7b112d57bb3feb9d6863b036747b1963f0 Reviewed-on: https://chromium-review.googlesource.com/1014126 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52649}
-
- 02 Mar, 2018 1 commit
-
-
Benedikt Meurer authored
This changes the BytecodeGraphBuilder to connect runtime calls that don't return normally, but always throw exceptions, to End (via a Throw node), instead of inserting Phis on the return values. This unblocks the new optimization approach for array iteration. Bug: v8:7510, v8:7514 Change-Id: Ic78216cc27034f191c4850e476f24e598c17deca Reviewed-on: https://chromium-review.googlesource.com/946250Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51702}
-
- 13 Oct, 2017 1 commit
-
-
Mathias Bynens authored
New code should use nullptr instead of NULL. This patch updates existing use of NULL to nullptr where applicable, making the code base more consistent. BUG=v8:6928,v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c Reviewed-on: https://chromium-review.googlesource.com/718338 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48557}
-
- 01 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
-
- 09 Jan, 2017 1 commit
-
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
- 30 Sep, 2016 1 commit
-
-
leszeks authored
matching function, creates a hashmap the specialises the case of keys that simply check pointer equality. I measure an average ~1% improvement on Octane code-load. Review-Url: https://codereview.chromium.org/2369963002 Cr-Commit-Position: refs/heads/master@{#39920}
-
- 12 Sep, 2016 1 commit
-
-
rmcilroy authored
Rework Runtime::FunctionForName to take a c-string instead of a v8::String so that the parser can parse native syntax runtime calls without doing on-the-fly internalization. Also adds a c-string variant of IntrinsicIndexForName for the same reasons. BUG=v8:5215,chromium:634953 Review-Url: https://codereview.chromium.org/2324803002 Cr-Commit-Position: refs/heads/master@{#39346}
-
- 11 Feb, 2016 3 commits
-
-
cbruni authored
Additionally list C++ builtins as well under --runtime_call_stats. Let's try to keep all counters in one place, that makes it a bit easier to maintain and especially discard unused ones. BUG= Committed: https://crrev.com/6bc71431995d49d4ca4a2ea9c75e5add5f345225 Cr-Commit-Position: refs/heads/master@{#33847} Review URL: https://codereview.chromium.org/1678973002 Cr-Commit-Position: refs/heads/master@{#33893}
-
cbruni authored
Revert of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1688783005/ ) Reason for revert: failing gc-stress tests Original issue's description: > Reland of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1681923003/ ) > > Reason for revert: > This CL was not the cause for the TSAN failures, the instruction-selector backend for x64 emitted a wrong compare which accidentally showed up with tsan + code moves. > The instruction-selectors changes have been reverted with https://codereview.chromium.org/1693433002 > > Original issue's description: > > Revert of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1678973002/ ) > > > > Reason for revert: > > [Sheriff] Breaks TSAN: > > https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7727 > > > > Original issue's description: > > > [counters] moving runtime counters to counter.h > > > > > > Additionally list C++ builtins as well under --runtime_call_stats. > > > Let's try to keep all counters in one place, that makes it a bit > > > easier to maintain and especially discard unused ones. > > > > > > BUG= > > > > > > Committed: https://crrev.com/6bc71431995d49d4ca4a2ea9c75e5add5f345225 > > > Cr-Commit-Position: refs/heads/master@{#33847} > > > > TBR=jarin@chromium.org,cbruni@chromium.org > > # Skipping CQ checks because original CL landed less than 1 days ago. > > NOPRESUBMIT=true > > NOTREECHECKS=true > > NOTRY=true > > BUG= > > > > Committed: https://crrev.com/2d669b96639517cfc33e6fc6d4c3814587bc7366 > > Cr-Commit-Position: refs/heads/master@{#33848} > > TBR=jarin@chromium.org,machenbach@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG= > > Committed: https://crrev.com/ad943fe44ede22b90b871e1233334dff5ff545c3 > Cr-Commit-Position: refs/heads/master@{#33887} TBR=jarin@chromium.org,machenbach@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/1687313002 Cr-Commit-Position: refs/heads/master@{#33889}
-
cbruni authored
Reland of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1681923003/ ) Reason for revert: This CL was not the cause for the TSAN failures, the instruction-selector backend for x64 emitted a wrong compare which accidentally showed up with tsan + code moves. The instruction-selectors changes have been reverted with https://codereview.chromium.org/1693433002 Original issue's description: > Revert of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1678973002/ ) > > Reason for revert: > [Sheriff] Breaks TSAN: > https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7727 > > Original issue's description: > > [counters] moving runtime counters to counter.h > > > > Additionally list C++ builtins as well under --runtime_call_stats. > > Let's try to keep all counters in one place, that makes it a bit > > easier to maintain and especially discard unused ones. > > > > BUG= > > > > Committed: https://crrev.com/6bc71431995d49d4ca4a2ea9c75e5add5f345225 > > Cr-Commit-Position: refs/heads/master@{#33847} > > TBR=jarin@chromium.org,cbruni@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG= > > Committed: https://crrev.com/2d669b96639517cfc33e6fc6d4c3814587bc7366 > Cr-Commit-Position: refs/heads/master@{#33848} TBR=jarin@chromium.org,machenbach@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= Review URL: https://codereview.chromium.org/1688783005 Cr-Commit-Position: refs/heads/master@{#33887}
-
- 09 Feb, 2016 2 commits
-
-
machenbach authored
Revert of [counters] moving runtime counters to counter.h (patchset #1 id:1 of https://codereview.chromium.org/1678973002/ ) Reason for revert: [Sheriff] Breaks TSAN: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/7727 Original issue's description: > [counters] moving runtime counters to counter.h > > Additionally list C++ builtins as well under --runtime_call_stats. > Let's try to keep all counters in one place, that makes it a bit > easier to maintain and especially discard unused ones. > > BUG= > > Committed: https://crrev.com/6bc71431995d49d4ca4a2ea9c75e5add5f345225 > Cr-Commit-Position: refs/heads/master@{#33847} TBR=jarin@chromium.org,cbruni@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/1681923003 Cr-Commit-Position: refs/heads/master@{#33848}
-
cbruni authored
Additionally list C++ builtins as well under --runtime_call_stats. Let's try to keep all counters in one place, that makes it a bit easier to maintain and especially discard unused ones. BUG= Review URL: https://codereview.chromium.org/1678973002 Cr-Commit-Position: refs/heads/master@{#33847}
-
- 22 Jan, 2016 1 commit
-
-
jarin authored
In d8, run with --runtime-call-stats and it will output the stats when d8 finishes. In Chrome, run the following: (only on trusted code, this punches *massive* security hole into Chrome) chrome --js-flags="--runtime-call-stats --allow-natives-syntax" To get the stats in the console, just run console.log(%GetAndResetRuntimeCallStats()); To output stats every second: setInterval(function() { console.log(%GetAndResetRuntimeCallStats()); }, 1000) Review URL: https://codereview.chromium.org/1615943002 Cr-Commit-Position: refs/heads/master@{#33462}
-
- 15 Jan, 2016 1 commit
-
-
rmcilroy authored
Adds a ForInPrepare Runtime function which returns a triple of cache_type, cache_array and cache_length. This requires adding support to CEntryStub to call runtime functions which return a ObjectTriple - a struct containing three Object* pointers. Also did some cleanup of the x64 CEntryStub to avoid replicated code. Replaces the interpreter's use of the ad-hock InterpreterForInPrepare Runtime function with ForInPrepare in preparation for fixing deopt in BytecodeGraphBuilder for ForIn (which will be done in a followup CL). MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1576093004 Cr-Commit-Position: refs/heads/master@{#33334}
-
- 02 Oct, 2015 2 commits
-
-
rmcilroy authored
Adds support for calling runtime functions from the interpreter. Adds the CallRuntime bytecode which takes a Runtime::FunctionId of the function to call and the arguments in sequential registers. Adds a InterpreterCEntry builtin to enable the interpreter to enter C++ code based on the functionId. Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall and groups all the interpreter builtins together. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1362383002 Cr-Commit-Position: refs/heads/master@{#31089}
-
rmcilroy authored
Revert of [Interpreter] Add CallRuntime support to the interpreter. (patchset #8 id:220001 of https://codereview.chromium.org/1362383002/ ) Reason for revert: Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot) Original issue's description: > [Interpreter] Add CallRuntime support to the interpreter. > > Adds support for calling runtime functions from the interpreter. Adds the > CallRuntime bytecode which takes a Runtime::FunctionId of the function to call > and the arguments in sequential registers. Adds a InterpreterCEntry builtin > to enable the interpreter to enter C++ code based on the functionId. > > Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall > and groups all the interpreter builtins together. > > BUG=v8:4280 > LOG=N > TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4280 Review URL: https://codereview.chromium.org/1379933003 Cr-Commit-Position: refs/heads/master@{#31078}
-