- 20 Aug, 2019 1 commit
-
-
Leszek Swirski authored
Since the mutability of HeapNumbers is determined by their owning object's descriptor array, we can remove the MutableHeapNumber type entirely, at the cost of a few fewer DCHECKs and a couple of TODOs to use the descriptor array information. This is a necessary step towards a follow-up which allows in-place Double -> Tagged transitions Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/ Bug: v8:9606 Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63294}
-
- 31 Jul, 2019 1 commit
-
-
Seth Brenith authored
This is a reland of 4b15b984 Updates since original: fix an arithmetic overflow bug, remove an invalid DCHECK, add a unit test that would trigger that DCHECK. Original change's description: > [regexp] Better quick checks on loop entry nodes > > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this > change is inspired by attempting to exit earlier from generated RegExp > code, when no further matches are possible because any match would be > too long. The motivating example this time is the following expression, > which tests whether a string of Unicode playing cards has five of the > same suit in a row: > > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u > > A human reading this expression can readily see that any match requires > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for > each repeated option reports its minimum distance to the end of a match > as zero. This is correct, because the LoopChoiceNode's behavior depends > on additional state (the loop counter). However, the preceding node, a > SET_REGISTER action that initializes the loop counter, could confidently > state that it consumes at least 10 characters. Furthermore, when we try > to emit a quick check for that action, we could follow only paths from > the LoopChoiceNode that are possible based on the minimum iteration > count. This change implements both of those "could"s. > > I expect this improvement to apply pretty broadly to expressions that > use minimum repetition counts and that don't meet the criteria for > unrolling. In this particular case, I get about 12% improvement on the > overall UniPoker test, due to reducing the execution time of this > expression by 85% and the execution time of another similar expression > that checks for n-of-a-kind by 20%. > > Bug: v8:9305 > > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62963} Bug: v8:9305 Change-Id: I992070d383009013881bf778242254c27134b650 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63009}
-
- 30 Jul, 2019 1 commit
-
-
Leszek Swirski authored
This reverts commit 4b15b984. Reason for revert: UBSan failure (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906578530303352544/+/steps/Check/0/logs/regress-126412/0). Original change's description: > [regexp] Better quick checks on loop entry nodes > > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this > change is inspired by attempting to exit earlier from generated RegExp > code, when no further matches are possible because any match would be > too long. The motivating example this time is the following expression, > which tests whether a string of Unicode playing cards has five of the > same suit in a row: > > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u > > A human reading this expression can readily see that any match requires > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for > each repeated option reports its minimum distance to the end of a match > as zero. This is correct, because the LoopChoiceNode's behavior depends > on additional state (the loop counter). However, the preceding node, a > SET_REGISTER action that initializes the loop counter, could confidently > state that it consumes at least 10 characters. Furthermore, when we try > to emit a quick check for that action, we could follow only paths from > the LoopChoiceNode that are possible based on the minimum iteration > count. This change implements both of those "could"s. > > I expect this improvement to apply pretty broadly to expressions that > use minimum repetition counts and that don't meet the criteria for > unrolling. In this particular case, I get about 12% improvement on the > overall UniPoker test, due to reducing the execution time of this > expression by 85% and the execution time of another similar expression > that checks for n-of-a-kind by 20%. > > Bug: v8:9305 > > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62963} TBR=jgruber@chromium.org,seth.brenith@microsoft.com Change-Id: Iac085b75e054fdf0d218987cfe449be1f1630545 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9305 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725621Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#62977}
-
- 29 Jul, 2019 1 commit
-
-
Seth Brenith authored
Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this change is inspired by attempting to exit earlier from generated RegExp code, when no further matches are possible because any match would be too long. The motivating example this time is the following expression, which tests whether a string of Unicode playing cards has five of the same suit in a row: /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u A human reading this expression can readily see that any match requires at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for each repeated option reports its minimum distance to the end of a match as zero. This is correct, because the LoopChoiceNode's behavior depends on additional state (the loop counter). However, the preceding node, a SET_REGISTER action that initializes the loop counter, could confidently state that it consumes at least 10 characters. Furthermore, when we try to emit a quick check for that action, we could follow only paths from the LoopChoiceNode that are possible based on the minimum iteration count. This change implements both of those "could"s. I expect this improvement to apply pretty broadly to expressions that use minimum repetition counts and that don't meet the criteria for unrolling. In this particular case, I get about 12% improvement on the overall UniPoker test, due to reducing the execution time of this expression by 85% and the execution time of another similar expression that checks for n-of-a-kind by 20%. Bug: v8:9305 Change-Id: I319e381743967bdf83324be75bae943fbb5dd496 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62963}
-
- 08 Jun, 2019 1 commit
-
-
Benedikt Meurer authored
The CloneObject bytecode was only able to handle objects, null and undefined, and explicit bytecode had to be generated to perform the ToObject outside the bytecode (unlike the other IC bytecodes that just perform the ToObject implicitly). That means the simplest possible object cloning would also generate a sequence of 5 bytecodes (at least): ``` Mov <register>, a0 JumpIfNull @1 JumpIfUndefined @1 ToObject <register> 1: CloneObject <register> ``` That is quite wasteful and unnecessary, since the core logic in the runtime already does the ToObject properly anyways. This change refactors the CloneObjectIC slightly to behave more like the other ICs and do the ToObject implicitly when necessary. Bug: v8:7611, v8:9114, v8:9183, v8:9343 Change-Id: I11973e90bf875f154a5a7739287bee17041e4a7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649554Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62064}
-
- 03 May, 2019 1 commit
-
-
Ross McIlroy authored
Bug: v8:8801, v8:8394 Change-Id: I6bb46ecafe1bd94adbf0409f13c9b2e558da0823 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594558 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#61200}
-
- 29 Apr, 2019 1 commit
-
-
Benedikt Meurer authored
This adds a new %_CopyDataProperties intrinsic, that reuses most of the existing machinery that we already have in place for Object.assign() and computed property names in object literals. This speeds up the general case for object spread (where the spread is not the first item in an object literal) and brings it on par with Object.assign() at least - in most cases it's significantly faster than Object.assign(). In the test case [1] referenced from the bug, the performance goes from objectSpreadLast: 3624 ms. objectAssignLast: 1938 ms. to objectSpreadLast: 646 ms. objectAssignLast: 1944 ms. which corresponds to a **5-6x performance boost**, making object spread faster than Object.assign() in general. Drive-by-fix: This refactors the Object.assign() fast-path in a way that it can be reused appropriately for object spread, and adds another new builtin SetDataProperties, which does the core of the Object.assign() work. We can teach TurboFan to inline Object.assign() based on the new SetDataProperties builtin at some later point to further optimize Object.assign(). [1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0 Bug: v8:9167 Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61100}
-
- 27 Nov, 2018 1 commit
-
-
Caitlin Potter authored
This avoids leaving the heap in an invalid state if a GC occurs during population of the cloned property array, as is done in other IC builtins. BUG=chromium:904167, v8:7611 R=jkummerow@chromium.org, ishell@chromium.org Change-Id: I0350ed2d65b72e299f7109b7d5aa86331f60e940 Reviewed-on: https://chromium-review.googlesource.com/c/1350282 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57879}
-
- 08 Nov, 2018 1 commit
-
-
Caitlin Potter authored
Change the macros added in bf84766a to only do the hard work if FLAG_unbox_double_fields is unset (otherwise, they will attempt to dereference raw float64s, which is bad!) Also adds a write barrier in CopyPropertyArrayValues for each store if it's possible that a MutableHeapNumber is cloned. BUG=chromium:901301, chromium:902965, chromium:903070, v8:7611 R=cbruni@chromium.org, jkummerow@chromium.org, ishell@chromium.org Change-Id: I224d3c4e7b0a887684bff68985b4d97021ba4cfb Reviewed-on: https://chromium-review.googlesource.com/c/1323911 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57368}
-
- 07 Nov, 2018 1 commit
-
-
Caitlin Potter authored
Adds a helper macro "CloneIfMutablePrimitive", which tests if the operand is a MutableHeapNumber, and if so, clones it, otherwise returning the original value. Also modifies the signature of "CopyPropertyArrayValues" to take a "DestroySource" enum, indicating whether or not the resulting object is supplanting the source object or not, and removes all default parameters from that macro (which were not used anyways). This corrects the issue reported in chromium:901301, where StaNamedOwnProperty was replacing the value of a MutableHeapNumber referenced by both the cloned object and the source object. BUG=chromium:901301, v8:7611 R=cbruni@chromium.org, jkummerow@chromium.org Change-Id: I43df1ddc84dfa4840e680b6affeba452ce0b6629 Reviewed-on: https://chromium-review.googlesource.com/c/1318096 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#57304}
-
- 11 Sep, 2018 1 commit
-
-
Caitlin Potter authored
The CSA implementation is a separate handler so that TF has the opportunity to reduce to a direct call, skipping some of the dispatching in the CloneObjectIC stub. This patch moves the looping over a source object's keys and values into the base CodeStubAssembler, so that it can be shared between ObjectAssignFast and CloneObjectIC_Slow. During each step of the loop, storing is delegated to a new SetPropertyInLiteral helper in KeyedStoreGenericGenerator, which performs a store without consulting the prototype chain, and automatically reconfigures accessors into data properties regardless of their attributes. BUG=v8:8067, v8:7611 R=ishell@chromium.org, jkummerow@chromium.org Change-Id: I06ae89f37e9b4265aab67389cf68a96529f90578 Reviewed-on: https://chromium-review.googlesource.com/1182122 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#55806}
-
- 04 Aug, 2018 1 commit
-
-
Caitlin Potter authored
This fixes a CHECK failure in MapVerify, and gets the correct behaviour for uses of the well-known symbols. BUG=v8:7611, chromium:866229 R=jkummerow@chromium.org, mvstanton@chromium.org, bmeurer@chromium.org Change-Id: I5d679357b8807ea9d1054121d8d336fe0dd43c7c Reviewed-on: https://chromium-review.googlesource.com/1162278Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#54905}
-
- 01 Aug, 2018 1 commit
-
-
Caitlin Potter authored
An object with a deprecated Map which has already been cached in CloneObjectIC feedback is still a valid Map for fast cloning --- but to be consistent with other ICs, deprecated maps are ignored, and are expected to be transitioned away from. If the source object has a deprecated map, the instance is migrated. BUG=v8:7611, chromium:867958, chromium:868586, chromium:869342, chromium:869347, chromium:869293 R=jkummerow@chromium.org, mvstanton@chromium.org Reviewed-on: https://chromium-review.googlesource.com/1154143 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#54799} Change-Id: I6e2f7b28c41bb9bd6255441da0f209a97bce5e8f Reviewed-on: https://chromium-review.googlesource.com/1157142 Cr-Commit-Position: refs/heads/master@{#54830}
-
- 31 Jul, 2018 2 commits
-
-
Michael Achenbach authored
This reverts commit d9f6c685. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20gc%20stress/17584 Original change's description: > Reland [CloneObjectIC] overwrite monomorphic/polymorphic feedback if deprecated > > An object with a deprecated Map which has already been cached in > CloneObjectIC feedback is still a valid Map for fast cloning --- but > to be consistent with other ICs, deprecated maps are ignored, and are > expected to be transitioned away from. > > If the source object has a deprecated map, the instance is migrated. > > BUG=v8:7611, chromium:867958, chromium:868586 > R=jkummerow@chromium.org, mvstanton@chromium.org > > Change-Id: I477aec6c8d0ae1e1648a70e85d2fd46146521d1c > Reviewed-on: https://chromium-review.googlesource.com/1154143 > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#54799} TBR=jkummerow@chromium.org,mvstanton@chromium.org,caitp@igalia.com Change-Id: Ifcb422c3a692543490710d450590323524a6359a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7611, chromium:867958, chromium:868586 Reviewed-on: https://chromium-review.googlesource.com/1155593Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#54800}
-
Caitlin Potter authored
An object with a deprecated Map which has already been cached in CloneObjectIC feedback is still a valid Map for fast cloning --- but to be consistent with other ICs, deprecated maps are ignored, and are expected to be transitioned away from. If the source object has a deprecated map, the instance is migrated. BUG=v8:7611, chromium:867958, chromium:868586 R=jkummerow@chromium.org, mvstanton@chromium.org Change-Id: I477aec6c8d0ae1e1648a70e85d2fd46146521d1c Reviewed-on: https://chromium-review.googlesource.com/1154143 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54799}
-
- 27 Jul, 2018 2 commits
-
-
Deepti Gandluri authored
This reverts commit 670fa86f. Reason for revert: Causes gc-stress bots to fail - https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8939819990688690880/+/steps/Check_-_d8/0/logs/object-spread-ic/0 https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8939819696982258192/+/steps/Check_-_d8/0/logs/object-spread-ic/0 Original change's description: > [CloneObjectIC] overwrite monomorphic/polymorphic feedback if deprecated > > An object with a deprecated Map which has already been cached in > CloneObjectIC feedback is still a valid Map for fast cloning --- but > to be consistent with other ICs, deprecated maps are ignored, and are > expected to be transitioned away from. > > If the source object has a deprecated map, the instance is migrated. > > BUG=v8:7611, chromium:867958 > R=jkummerow@chromium.org, mvstanton@chromium.org > > Change-Id: I9771b00400fb4dda45a62e874a31d9b50630d847 > Reviewed-on: https://chromium-review.googlesource.com/1152414 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Caitlin Potter <caitp@igalia.com> > Cr-Commit-Position: refs/heads/master@{#54758} TBR=jkummerow@chromium.org,mvstanton@chromium.org,caitp@igalia.com Change-Id: Id17652ad6f3f09adb43848069549ad146d48b2d7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7611, chromium:867958 Reviewed-on: https://chromium-review.googlesource.com/1153747Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#54760}
-
Caitlin Potter authored
An object with a deprecated Map which has already been cached in CloneObjectIC feedback is still a valid Map for fast cloning --- but to be consistent with other ICs, deprecated maps are ignored, and are expected to be transitioned away from. If the source object has a deprecated map, the instance is migrated. BUG=v8:7611, chromium:867958 R=jkummerow@chromium.org, mvstanton@chromium.org Change-Id: I9771b00400fb4dda45a62e874a31d9b50630d847 Reviewed-on: https://chromium-review.googlesource.com/1152414Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#54758}
-
- 25 Jul, 2018 1 commit
-
-
Caitlin Potter authored
Includes fixes for several ClusterFuzz regressions: 1) fix an invalid Handle-cast in ic.cc (chromium:866282) 2) fix for improper accounting of used/unused inobject fields, found by clusterfuzz (chromium:866357). 3) fix number of control outputs for the JSCloneObject operator to be used by IfSuccess and IfException nodes (chromium:866727). 4) fix property constness in out-of-object properties of fast-cloned object to be compatible with DCHECKs in StoreIC (chromium:866861). Also includes the fixups missing from the initial commit, and regression tests BUG=v8:7611, chromium:866282, chromium:866357, chromium:866727, chromium:866861 R=jkummerow@chromium.org, mvstanton@chromium.org TBR=rmcilroy@chromium.org Change-Id: I77220308482f16db2893c0dcebec36530d0f5540 Reviewed-on: https://chromium-review.googlesource.com/1146297 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#54706}
-
- 20 Jul, 2018 1 commit
-
-
Caitlin Potter authored
As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
-
- 20 Feb, 2018 1 commit
-
-
Yang Guo authored
Until now lookbehind assertions have been quantifiable in non-unicode regexps. This seems to be an oversight in the spec. R=jgruber@chromium.org Bug: v8:7462 Change-Id: Iad0db441089c7510dd2c42a861db92c05545ce1e Reviewed-on: https://chromium-review.googlesource.com/926102 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51392}
-
- 28 Nov, 2017 1 commit
-
-
Adam Klein authored
It was shipped in Chrome 62. Bug: v8:5546, v8:4829 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I3ac318639f1f7483d4d4f4fe5606387a856be98a Reviewed-on: https://chromium-review.googlesource.com/777940Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49687}
-
- 17 Nov, 2017 1 commit
-
-
Adam Klein authored
Both of these features were shipped in Chrome 62. Bug: v8:4545, v8:6172 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ie00dcbeded7517a15696d4a78fcfbbf162919923 Reviewed-on: https://chromium-review.googlesource.com/775601Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49453}
-
- 25 Oct, 2017 1 commit
-
-
Adam Klein authored
This flag has been on by default since Chrome 61. Bug: v8:5549 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I81c34d1d3a7dbd219acce2cdf0cf4917eb484002 Reviewed-on: https://chromium-review.googlesource.com/738312Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48945}
-