- 08 Apr, 2019 8 commits
-
-
Sigurd Schneider authored
Change-Id: I90be28728842a1ab5a4d4d674298e71f70043e80 Notry: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549163 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#60677}
-
Sigurd Schneider authored
Change-Id: I51e32bc344c80d67a23d33039fda49bb9620a78f Notry: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549165 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
This ensures that ApiObjects in V8 are not dropped if they are currently used as WeakCollection keys. As proxy to determine key status we use the presence of the identity hash on the object. R=ulan@chromium.org Bug: v8:8557, chromium:949244 Change-Id: Ifa0e24be44431a0200fd6a1d9898cd366b940bd5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557143Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60675}
-
Georg Neis authored
R=bmeurer@chromium.org Change-Id: Ibfe4a0f12eedd2b4d6a5614e99f2076c026aea24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557141Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60674}
-
Pierre Langlois authored
We would only increment write barrier counters from the the MacroAssembler's RecordWrite method which is only used in limited cases. Instead, we should increment it inside the RecordWrite stub, this way we catch all uses, including WASM. Also, we had a static counter aimed at telling us how many barriers exist in generated code, as opposed to how many are executed. This counter was not functional since the compiler isn't aware of counters at the moment. Let's just remove it to avoid confusion. Change-Id: I6b173ab858c8984ef03ede225afdc999ba82b5c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524483Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#60673}
-
Peter Marshall authored
Remove unused includes and add includes that were indirect. Remove UnboundQueue which was not used anywhere. Change-Id: If47faac45fc9c16a27453ecabed927ea00df3045 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557136 Auto-Submit: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#60672}
-
Michael Achenbach authored
The test is so slow that it might have caused the test driver to hang after the normal hard timeout. TBR=sergiyb@chromium.org NOTRY=true Bug: v8:9098 Change-Id: I28ad1551f66fab989494d7a3b015d661c5ab6efb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557142Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9baa370..7db6cfc TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I11f6f1b06a50204af8a01c22324a187536697e6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557341Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#60670}
-
- 07 Apr, 2019 2 commits
-
-
Michael Achenbach authored
TBR=tmrts@chromium.org NOTRY=true Bug: v8:9098 Change-Id: I69d9cd21ad70357a77b45e97393949f1cfbab529 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557137Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/25794eb..9baa370 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/78cdfa0..979fc35 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/9198ef8..0b62ed7 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Iadb495d5260033a5afef74dcbe4704f526ade325 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1556580Reviewed-by:
-
- 06 Apr, 2019 2 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/96d2ee3..25794eb Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/63e0762..78cdfa0 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/b8268ca..9198ef8 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/25ef1f6..f822215 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Ie655b9676aec2df3d2226c73ad7e36fcca13ebaf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1556574Reviewed-by:
-
Deepti Gandluri authored
Change-Id: Ic00f8e0ac9ef621354b74ffa7c83a84301c46222 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1555435Reviewed-by:
Ben Smith <binji@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#60666}
-
- 05 Apr, 2019 23 commits
-
-
Pierre Langlois authored
The --trace-gc-verbose flag was mistakenly reporting the generic LO space size in place of the *code* LO space size. Change-Id: Iddb83b540b0e0a201aa358649d91ef606721e0be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554693 Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#60665}
-
Ben Smith authored
This is a reland of 63608968 The previous CL failed on Windows, but it was a general bug. The dropped_elem_segments was not being set on the instance properly in cctests, so`table.init` instructions would fail by reading uninitialized data. I took this opportunity to also add an implementation of `elem.drop` in the interpreter, and ported the JS tests for those too. Original change's description: > [wasm] Implement table.init for interpreter > > This also fixes CheckCallViaJS when a trap occurs. In that case, the > trap callback is called instead of an exception being thrown, so if it > isn't handled, a bogus result will be returned instead. > > Bug: v8:8965 > Change-Id: I560e89f353756df23c062fb8c9484d9971c19253 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Ben Smith <binji@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60473} Bug: v8:8965 Change-Id: Ia547d9530b7ca67fde5bd94539f49153b796e82d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547142 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60664}
-
Sergiy Belozorov authored
Testing V8 CQ after https://crrev.com/i/1139317 and https://crrev.com/i/1141184, which are changing how host_class dimension is computed and set and how xenial bots are provisioned. TBR=tandrii@chromium.org, machenbach@chromium.org No-Tree-Checks: true Change-Id: Id7fcda589764b7048f19df97b3bea6e2ad7c97be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554694 Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
Sergiy Belozorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#60663}
-
Frank Tang authored
Bug: v8:9040 Change-Id: Ie1c5ab982aef844c704dba5bb9a0e945ce220545 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549435Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#60662}
-
Vadim Gorbachev authored
use '!=' instead of 'is not' with str FileNotFoundError isn't exist in python2.7, use IOError instead. Bug: chromium:948812 Change-Id: I241ff8a9321d612f2371a2a2e2deae948fa180e5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549168 Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org> Reviewed-by:
-
Vadim Gorbachev authored
For details see: https://python-future.org/compatible_idioms.html#file Bug: chromium:948824 Change-Id: Ib06568963073621bd8edf2c8edb89bf8253d3bcb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549169Reviewed-by:
-
Simon Zünd authored
As part of one of the stack trace refactorings, this field moved from StackFrameInfo to the StackTraceFrame class, but was not properly removed. R=petermarshall@chromium.org Bug: v8:8742 Change-Id: I18b9bd7650eed0f5bdb0823da9fdefb6afa3491e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550800Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60659}
-
Michael Starzinger authored
This makes sure that the implicit operand stack slot used for passing an exception from the throw-site to the catch-site is counted against the maximum stack height. R=clemensh@chromium.org TEST=mjsunit/wasm/exceptions-rethrow-interpreter BUG=v8:8091 Change-Id: I7e8f47ba4662eb273792e7508207f67588264a2f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554683 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60658}
-
Georg Neis authored
Bug: v8:9087 Change-Id: Ibc21d7e5619e4e6a0edc98cb0bd12e67ab2f6643 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554690Reviewed-by:
-
Michael Achenbach authored
For standard test failures, the variant name is enough to deduce the full command line of the test. This is used to create the flako command line on the infra side. Test failures from numfuzz have additional variant_flags, calculated by the fuzzer, which don't match a variant name. Exposing those in the test results will enable printing a proper flako command line on infra side for numfuzz cases. Bug: v8:8971 Change-Id: Ie47d42a0b34037da458b474f2a9ab38f1a5d238a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554689Reviewed-by:
-
Michael Starzinger authored
R=clemensh@chromium.org TEST=mjsunit/wasm/exceptions-simd-interpreter BUG=v8:8091 Change-Id: Id0b5da98bbfb91c7a5a878681d7fffe81233284f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552794 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
This introduces a new PROTOTYPE_DESCRIPTOR_ARRAY_TYPE, which is used to be able to distinguish DescriptorArrays for prototypes from regular ones. This is primarily useful for the live objects, since for dead DescriptorArrays we will likely not be able to figure out whether they belong to a prototype Map, unless they die together. Bug: v8:7266 Change-Id: I4b8e0008cc8bae607778151b7c18d30f4efba88d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554687Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60654}
-
Clemens Hammacher authored
This is a reland of d746be9c Original change's description: > [wasm] Use work-stealing queues for background compilation > > This reduces contention on the mutex protecting the {CompilationState} > by splitting the compilation unit queues into several queues (one per > background task). Each task executes its own queue first, and steals > from other queues once it runs out of work. > The implementation of the set of work-stealing queues is encapsulated > in the new {CompilationUnitQueues} class in module-compiler.cc. > > R=titzer@chromium.org > > Bug: v8:8916 > Change-Id: I5a40314917e7d4a35d7ff9e8ec124ec212beacab > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543350 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60572} Bug: v8:8916 Change-Id: Ic0cbad0ddc31be24715c5490b9ec71a39186fd3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549172 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Anna Henningsen authored
Typed arrays with elements cannot be frozen, but this function previously would have falsely reported that they are after an `Object.freeze()` call. Since the latter bails out when the object is already frozen, the effect was that when calling `Object.freeze()` on a typed array more than once, the first call would throw and subsequent ones would not. Change-Id: I75e59f51ebb94797cdf39bac4ec4c25c547e70a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552781 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
This introduces new virtual instance types to further diagnose what's going on in MapSpace, namely: - MAP_ABANDONED_PROTOTYPE_TYPE includes all the abandoned (fast-mode) prototype maps. - MAP_DEPRECATED_TYPE includes all the deprecated (fast-mode) maps. - MAP_DICTIONARY_TYPE includes all the dictionary-mode maps. - MAP_PROTOTYPE_DICTIONARY_TYPE includes all the prototype maps in dictionary-mode. - MAP_PROTOTYPE_TYPE includes all the prototype maps in fast-mode. - MAP_STABLE_TYPE includes all the (fast-mode) stable (leaf) maps. Those maps who don't fall into any of the buckets above are categorized as MAP_TYPE (as before). The naming was chosen like this to make it possible to filter for the relevant maps in the object stats via 'MAP_.*_TYPE'. Bug: v8:7266 Change-Id: I233734e96a390ddb391bfff8a34a8fec842d1f7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554685Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
-
Michael Starzinger authored
This ensures the lifetime of reference values on the simulated operand stack of the interpreter is coupled to a lifetime of the {ThreadImpl}. We no longer directly store reference values on the stack, but maintain a separate "reference stack" on the GC'ed heap. This will ensure the GC traces such references properly. The new {StackValue} safety wrapper makes sure all use-sites that access the operand stack properly convert to/from handles when dealing with reference values. R=clemensh@chromium.org TEST=mjsunit/wasm/exceptions-interpreter BUG=v8:8091,v8:7581 Change-Id: I8c05f2d945a6def943b89be0cfca538a73df8855 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552791 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: -
tzik authored
This expose v8::Context::DetachGlobal() as Realm.detachGlobal() in d8, so that we can test API behaviors on Blink's detached iframes. Change-Id: I4de1dd1a20d5862aba709e36d1d6afa9b221df6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554322Reviewed-by:
-
Benedikt Meurer authored
This is the first step towards full huge typed array support in V8. Before this change, the JSTypedArray::length and the elements backing store length (FixedTypedArrayBase::length) were used more or less interchangeably to determine the number of elements in a JSTypedArray. With this change we disentangle these two lengths, and instead make JSTypedArray::length authoritative. For on-heap typed arrays, the FixedTypedArrayBase::length will remain the number of elements in the backing store, but for the off-heap typed arrays, this length will be set to 0 (matching the fact that the FixedTypedArrayBase instance does not contain any elements itself). This also unifies the JSTypedArray::set_/length() and length_value() methods to only have JSTypedArray::set_/length() which returns/takes size_t values. Currently this still requires the values to be in Smi range, but later we will extend this to allow arbitrary size_t values (in the safe integer range). Bug: v8:4153, v8:7881 Change-Id: Iff9089130bb31fa9e08e0cf913e7ab52c3dbf107 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543729 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
-
Frank Tang authored
See https://chromium.googlesource.com/chromium/deps/icu/+/1552155 for changes. Correct test expectation based on icu64 changes. CL of Rolling the same ICU hash to DEPS in chromium/src Repo is in https://chromium-review.googlesource.com/c/chromium/src/+/1536613 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Bug: chromium:943348, v8:9052 Change-Id: I3a4579ba745f7f6a621b2059de325bea7a2472a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1536559Reviewed-by:
-
Frederik Gossen authored
Locks for compilation state callbacks and for the native module are again taken one after the other. As a consequence, publishing compiled Wasm code again happens in parallel. Compile times are now comparable to before lazy hints were enabled. Bug: chromium:949050 Change-Id: I45c52254d046de080938bd131fd3ed8116660bef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552787 Commit-Queue: Frederik Gossen <frgossen@google.com> Reviewed-by:
-
Clemens Hammacher authored
This reverts commit 1fb26d83. Reason for revert: Flushes out TSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/25782 Original change's description: > [regalloc] Enable control flow aware allocation > > This is a test to see how much and where we regress. We have seen > some quirks of our current allocator that do not show up in this > new approach, so we need to decide whether to stabilize the new > allocation scheme. Performance numbers are a key indicator for that > decision. > > This patch is intended to be reverted after stability and performance > numbers are in (i.e. after a few days). > > Change-Id: I8df8ff7de8efa82a8abbdfa1d21d7877756f129e > Bug: v8:9088 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552786 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60643} TBR=mstarzinger@chromium.org,jarin@chromium.org,sigurds@chromium.org Change-Id: Ia1934b01b0909479b2bd52ba686cc9b3fb364b4b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9088 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554682Reviewed-by:
-
Georg Neis authored
Bug: v8:9087 Change-Id: Ia806686b47f0e6ddc89f6b043df65ab8a931bbf8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552798Reviewed-by:
-
Sigurd Schneider authored
This is a test to see how much and where we regress. We have seen some quirks of our current allocator that do not show up in this new approach, so we need to decide whether to stabilize the new allocation scheme. Performance numbers are a key indicator for that decision. This patch is intended to be reverted after stability and performance numbers are in (i.e. after a few days). Change-Id: I8df8ff7de8efa82a8abbdfa1d21d7877756f129e Bug: v8:9088 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552786Reviewed-by:
-
- 04 Apr, 2019 5 commits
-
-
Deepti Gandluri authored
Change-Id: I453c356a6d9098739e7bf32d3c7a75c8afb7cab2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1554106Reviewed-by:
-
Deepti Gandluri authored
Some state related to WasmMemories is cached on the JSArrayBuffer object (is_growable, is_wasm_memory). The problem with this is in some PostMessage flows, this information can get lost depending on how JSArrayBuffers are deserialized. In this particular case when the WasmMemory is postMessaged, it goes through the Blink DedicatedWorkerMessagingProxy::PostMessageToWorkerGlobalScope flow, which reconstructs the ArrayBuffer from the backing store, and size, and loses the is_growable flag, leading to a failure to grow memory. Moving the is_growable flag so that AllocationData can be the source of truth for all wasm memory state, and is consistently preserved across PostMessage. Change-Id: I775f66ddeff68b8cafc18b75ca5460dfb0343c8b Bug: v8:9065 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549789 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#60641}
-
Jaroslav Sevcik authored
This makes the DCHECK consistent with the map updater. See https://cs.chromium.org/chromium/src/v8/src/map-updater.cc?l=330&rcl=5671f8b940b0fcdb550e318e449ded0f866e935a Bug: chromium:949435 Change-Id: Id4fef60cdca094e638a1db38878953ecb2422c4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552797Reviewed-by:
-
Daniel Clifford authored
Indexed fields in classes can now be initialized using iterators and a spread syntax, e.g.: class Foo { length: Smi; elements[length]: Object; } new Foo{length: 5, elements: ...iter}; where iter implements Torque's iterator protocol. This protocol requires the definition of a method with the following signature: Next(): <type> labels NoMore; Where <type> is the Torque type of the values to be iterated. In the case of indexed field initialization, the type must be the field's type or a subtype thereof. Field initialization with spread is desugared into a loop that calls the spread iterator's Next method and assigns each returned value in order to the corresponding indexed field element. The general machinery for the spread syntax has been added to the ast and parser, however, it can currently only be used in the specific context of indexed field initialization. Spread operators used in any other context will cause an error. Bug: v8:7793 Change-Id: If071e61db8166573c28d13318879c88ba96f6d98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550407 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#60639}
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: I1b9f3c0c805709c6570785ec9f1045f21c9d03e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541048Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
