- 12 Aug, 2019 1 commit
-
-
Yang Guo authored
R=machenbach@chromium.org Bug: chromium:992584 Change-Id: I301013731a502689f2edd5c90e5e7bf2136198c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745337Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63159}
-
- 09 Aug, 2019 1 commit
-
-
Michael Lippautz authored
- Adds regular native heap entries to the HeapObjectsMap. - Adds a side map for keeping a mapping of native objects to their canonical heap entry that they have been merged into. Change-Id: Ida00628126ded1948ceb2a0cbe14da817af7f361 Bug: chromium:988350 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720810 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63140}
-
- 05 Aug, 2019 2 commits
-
-
Ulan Degenbaev authored
This reverts commit 5611f70b. Reason for revert: flaky tests: v8:9588, v8:9587 Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5ae > > Contributed by titzer@chromium.org > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9380, v8:9221, chromium:986318 Change-Id: Ic7381239f4e90d0c437b7e47a5ac6e8bce60f882 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736747Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63081}
-
Simon Zünd authored
This CL changes {CreateApiFunction} to take an explicit native context to set on the newly created JSFunction. The CL also adds a new variant of {ApiNatives::InstatiateFunction}, that takes a native context and passes it through to {CreateApiFunction}. This is a refactoring in preparation for a bugfix. AccessorPairs can be instantiated lazily. At the time of lazy instantiation, the current context does not necessarily match the creation context of the holder of an AccessorPair. Bug: chromium:986063, chromium:989909 Change-Id: Idea4b5052f2baff5c3d916f5ab8ed5017b60699b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735308 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63063}
-
- 02 Aug, 2019 1 commit
-
-
Ulan Degenbaev authored
This is a reland of bc33f5ae Contributed by titzer@chromium.org Original change's description: > [arraybuffer] Rearchitect backing store ownership > > This CL completely rearchitects the ownership of array buffer backing stores, > consolidating ownership into a {BackingStore} C++ object that is tracked > throughout V8 using unique_ptr and shared_ptr where appropriate. > > Overall, lifetime management is simpler and more explicit. The numerous > ways that array buffers were initialized have been streamlined to one > Attach() method on JSArrayBuffer. The array buffer tracker in the > GC implementation now manages std::shared_ptr<BackingStore> pointers, > and the construction and destruction of the BackingStore object itself > handles the underlying page or embedder-allocated memory. > > The embedder API remains unchanged for now. We use the > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > keep the backing store alive properly, even in the case of aliases > from live heap objects. Thus the embedder has a lower chance of making > a mistake. Long-term, we should move the embedder to a model where they > manage backing stores using shared_ptr to an opaque backing store object. TBR=yangguo@chromium.org BUG=v8:9380,v8:9221,chromium:986318 Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63041}
-
- 31 Jul, 2019 3 commits
-
-
Francis McCabe authored
This reverts commit df8e6177. Reason for revert: Multiple flakes in apparently related areas: https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906409837768155568/+/steps/Check__flakes_/0/logs/BackingStoreTest.RacyGrowWasmMem.../0 Original change's description: > "Reland x3 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5ae > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > R=mlippautz@chromium.org > BUG=v8:9380,v8:9221,chromium:986318 > TBR=ulan@chromium.org > > Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63007} TBR=mstarzinger@chromium.org,titzer@chromium.org,mlippautz@chromium.org Change-Id: If0266e5893b1325a332d5986337fa7ece2cb6943 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9380, v8:9221, chromium:986318 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729549Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#63011}
-
Ben L. Titzer authored
This is a reland of bc33f5ae Original change's description: > [arraybuffer] Rearchitect backing store ownership > > This CL completely rearchitects the ownership of array buffer backing stores, > consolidating ownership into a {BackingStore} C++ object that is tracked > throughout V8 using unique_ptr and shared_ptr where appropriate. > > Overall, lifetime management is simpler and more explicit. The numerous > ways that array buffers were initialized have been streamlined to one > Attach() method on JSArrayBuffer. The array buffer tracker in the > GC implementation now manages std::shared_ptr<BackingStore> pointers, > and the construction and destruction of the BackingStore object itself > handles the underlying page or embedder-allocated memory. > > The embedder API remains unchanged for now. We use the > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > keep the backing store alive properly, even in the case of aliases > from live heap objects. Thus the embedder has a lower chance of making > a mistake. Long-term, we should move the embedder to a model where they > manage backing stores using shared_ptr to an opaque backing store object. R=mlippautz@chromium.org BUG=v8:9380,v8:9221,chromium:986318 TBR=ulan@chromium.org Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#63007}
-
Tom Tan authored
On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63002}
-
- 30 Jul, 2019 1 commit
-
-
Sathya Gunasekaran authored
Previously, this was run as a microtask and this CL changes it to run as a separate task as mandated by the current WeakRef spec. This CL also introduces a FinalizationGroup type to the V8 API representing the JSFinalizationGroup. This has a `Cleanup` function that runs the cleanup callback associated with it. SetHostCleanupFinalizationGroupCallback is added to set the embedder defined HostCleanupFinalizationGroupCallback. ClearKeptObject is exposed on the v8::Isolate to reset the strongly held set of objects. The general workflow is the following: (a) When the GC notices that a given finalization group has dirty cells, it calls HostCleanupFinalizationGroupCallback with the given finalization group. (b) As part of HostCleanupFinalizationGroupCallback, the embedder enqueues a task that at some point later calls FinalizationGroup::Cleanup. (c) At some point in the future, FinalizationGroup::Cleanup is called, which runs the cleanup callback of the finalization group. This patch also includes d8 changes to use these new APIs. Currently, d8 cycles through the enqueued finalization groups after a synchronous turn (and it's microtask checkpoint) and runs the cleanup callbacks. Change-Id: I06eb4da2c103b2792a9c62bc4b98fd4e5c4892fc Bug: v8:8179 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655655 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62984}
-
- 26 Jul, 2019 2 commits
-
-
Andrew Comminos authored
Implements ProfilerCodeObserver, a class to track the generation and movement of code on the heap for the lifetime of each CpuProfiler. When sampling is inactive, logged code is committed directly to the CodeMap. During profiling, ProfilerCodeObserver redirects these events onto the profiling thread for later dispatch. Bug: v8:9151 Change-Id: Ib5b152446d2a3838e1b00a80253fc4fbd2f6e8c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1604143Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Andrew Comminos <acomminos@fb.com> Cr-Commit-Position: refs/heads/master@{#62943}
-
Ulan Degenbaev authored
This reverts commit 1320c917. Reason for revert: The code in SFI is also flushed by the serializer with FunctionCodeHandling::kClear, so this fix does not work with --no_flush_bytecode. Original change's description: > [snapshot] Fix clearing of feedback vector in serializer (follow-up 2) > > Bug: v8:7857 > Change-Id: I3940ae2830adb6c572e079551b7bba7d84462afd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715444 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62881} TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7857 Change-Id: If85fe29b2cdf6523ee53895628da38d942d45c2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719190Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62935}
-
- 23 Jul, 2019 3 commits
-
-
Ulan Degenbaev authored
Bug: v8:7857 Change-Id: I3940ae2830adb6c572e079551b7bba7d84462afd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715444Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62881}
-
Ulan Degenbaev authored
The fix in https://chromium-review.googlesource.com/c/v8/v8/+/1698383 was not complete. We can have a case when a function is neither optmized or intepreted but still has a feedback vector. This can happen when the code of the function was flushed. Bug: v8:7857 Change-Id: I9cb6e474d79a5d4956301e87705af136baeaeb8a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714875 Auto-Submit: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62880}
-
Ben L. Titzer authored
This reverts commit 306cf403. Reason for revert: performance regressions / too near branch point TBR=mslekova@chromium.org BUG=v8:9380 Change-Id: If77630b73eafbf1190c823199fe2a34361da303f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714867Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62867}
-
- 22 Jul, 2019 1 commit
-
-
Ben L. Titzer authored
This is a reland of bc33f5ae Original change's description: > Reland "[arraybuffer] Rearchitect backing store ownership" > > This is a reland of 31cd5d83 > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > > > R=mlippautz@chromium.org > > BUG=v8:9380,v8:9221 > > > > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323 > > Commit-Queue: Ben Titzer <titzer@chromium.org> > > Reviewed-by: Ben Titzer <titzer@chromium.org> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#62572} > > Bug: v8:9380, v8:9221 > Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906 > Commit-Queue: Ben Titzer <titzer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62809} Bug: v8:9380, v8:9221 Change-Id: I9a2525753ae2424108d074fa81df5f25d945c824 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709409 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#62847}
-
- 19 Jul, 2019 1 commit
-
-
Yang Guo authored
Adds a new out param which allows accessing the ScriptOrModule of a function, which allows an embedder such as Node.js to use the function's i::Script lifetime. Refs: https://github.com/nodejs/node-v8/issues/111 Change-Id: I34346d94d76e8f9b8377c97d948673f4b95eb9d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699698Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62830}
-
- 18 Jul, 2019 2 commits
-
-
Clemens Hammacher authored
This reverts commit bc33f5ae. Reason for revert: Still failing (OOM on win32): https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/22210 Original change's description: > Reland "[arraybuffer] Rearchitect backing store ownership" > > This is a reland of 31cd5d83 > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > > > R=mlippautz@chromium.org > > BUG=v8:9380,v8:9221 > > > > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323 > > Commit-Queue: Ben Titzer <titzer@chromium.org> > > Reviewed-by: Ben Titzer <titzer@chromium.org> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#62572} > > Bug: v8:9380, v8:9221 > Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906 > Commit-Queue: Ben Titzer <titzer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62809} TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org Change-Id: Iea755df9aaa1e95d284135bd0a6681b1340b6832 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9380, v8:9221 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708487Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62811}
-
Ben L. Titzer authored
This is a reland of 31cd5d83 Original change's description: > [arraybuffer] Rearchitect backing store ownership > > This CL completely rearchitects the ownership of array buffer backing stores, > consolidating ownership into a {BackingStore} C++ object that is tracked > throughout V8 using unique_ptr and shared_ptr where appropriate. > > Overall, lifetime management is simpler and more explicit. The numerous > ways that array buffers were initialized have been streamlined to one > Attach() method on JSArrayBuffer. The array buffer tracker in the > GC implementation now manages std::shared_ptr<BackingStore> pointers, > and the construction and destruction of the BackingStore object itself > handles the underlying page or embedder-allocated memory. > > The embedder API remains unchanged for now. We use the > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > keep the backing store alive properly, even in the case of aliases > from live heap objects. Thus the embedder has a lower chance of making > a mistake. Long-term, we should move the embedder to a model where they > manage backing stores using shared_ptr to an opaque backing store object. > > R=mlippautz@chromium.org > BUG=v8:9380,v8:9221 > > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323 > Commit-Queue: Ben Titzer <titzer@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62572} Bug: v8:9380, v8:9221 Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62809}
-
- 12 Jul, 2019 1 commit
-
-
Ulan Degenbaev authored
The serializer clears JSFunctions together with feedback vectors assuming that there is one to one correspondence between them. That does not work in the case when there are multiple JSFunctions sharing the same feedback vector. This patch ensures that all such JSFunctions are properly cleared. Bug: v8:7857 Change-Id: Ie441089e12bda5a8be7f9bed90f7be9499938609 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698383Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#62673}
-
- 11 Jul, 2019 1 commit
-
-
Andreas Haas authored
At the moment we cancel all {AsyncCompileJobs} when a context of an isolate gets disposed. However, there can be multiple contexts per isolate, which meant that in some cases we canceled compilations even though their context was still alive. With this CL we only abort the compilations of the native context, which is typically the context that is being disposed. This is a small change that can be merged back. I plan to do a proper change later which extends the V8 API so that the embedder provides a handle to the context that is disposed. R=clemensh@chromium.org Bug: chromium:980876 Change-Id: I278bc30f084fe31fa409f1d4f913f1186b4809ec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692939 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62627}
-
- 08 Jul, 2019 2 commits
-
-
Clemens Hammacher authored
This reverts commit 31cd5d83. Reason for revert: It breaks my heart to revert this, but it fails differently on several bots, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/26671. Original change's description: > [arraybuffer] Rearchitect backing store ownership > > This CL completely rearchitects the ownership of array buffer backing stores, > consolidating ownership into a {BackingStore} C++ object that is tracked > throughout V8 using unique_ptr and shared_ptr where appropriate. > > Overall, lifetime management is simpler and more explicit. The numerous > ways that array buffers were initialized have been streamlined to one > Attach() method on JSArrayBuffer. The array buffer tracker in the > GC implementation now manages std::shared_ptr<BackingStore> pointers, > and the construction and destruction of the BackingStore object itself > handles the underlying page or embedder-allocated memory. > > The embedder API remains unchanged for now. We use the > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > keep the backing store alive properly, even in the case of aliases > from live heap objects. Thus the embedder has a lower chance of making > a mistake. Long-term, we should move the embedder to a model where they > manage backing stores using shared_ptr to an opaque backing store object. > > R=mlippautz@chromium.org > BUG=v8:9380,v8:9221 > > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323 > Commit-Queue: Ben Titzer <titzer@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62572} TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org Change-Id: Ib35788ba8c31192d90cbc72df3dbc41030f109de No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9380, v8:9221 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691034Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62578}
-
Ben L. Titzer authored
This CL completely rearchitects the ownership of array buffer backing stores, consolidating ownership into a {BackingStore} C++ object that is tracked throughout V8 using unique_ptr and shared_ptr where appropriate. Overall, lifetime management is simpler and more explicit. The numerous ways that array buffers were initialized have been streamlined to one Attach() method on JSArrayBuffer. The array buffer tracker in the GC implementation now manages std::shared_ptr<BackingStore> pointers, and the construction and destruction of the BackingStore object itself handles the underlying page or embedder-allocated memory. The embedder API remains unchanged for now. We use the v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to keep the backing store alive properly, even in the case of aliases from live heap objects. Thus the embedder has a lower chance of making a mistake. Long-term, we should move the embedder to a model where they manage backing stores using shared_ptr to an opaque backing store object. R=mlippautz@chromium.org BUG=v8:9380,v8:9221 Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#62572}
-
- 04 Jul, 2019 1 commit
-
-
Simon Zünd authored
This CL moves the code responsible for serializing a stack trace frame into a string, out of messages.cc and into stack-frame-info.cc. Instead of symbolizing the stack trace frame while serializing, the code is changed to work on top of StackTraceFrame and StackFrameInfo objects. The result is that the serialization code no longer cares when a stack trace frame is symbolized. Symbolization could happen eagerly during capturing, or lazily the first time any of StackFrameInfo fields are accessed. Drive-by: Existing users of StackFrameBase::ToString are adapted to the new SerializeStackTraceFrame API. This includes Isolate::PrintCurrentStackTrace, which is changed to re-use the existing capturing and serializing mechanism. Bug: v8:8742 Change-Id: Ic7fd80668c9d993e99d586ef7fe022850104c34f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631414 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#62522}
-
- 28 Jun, 2019 1 commit
-
-
Yang Guo authored
TBR=luoe@chromium.org Bug: chromium:976713 Change-Id: Ib92c6054a017a94ad23721de240b8a20d87c9f85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680544Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62437}
-
- 27 Jun, 2019 1 commit
-
-
Daniel Clark authored
This change is a partial implementation of Synthetic Module Record as specified here: https://heycam.github.io/webidl/#synthetic-module-records This includes: - Introduce SyntheticModule class inheriting from Module. - Extend v8::Module interface in v8.h to include Synthetic Module APIs, with corresponding implementations in api.cc. - Provide SyntheticModule implementations of PrepareInstantiate, FinishInstantiate, and SetExport. - Provide cctest unit tests for the implementations in the preceding item. We will follow up with further submissions to implement the remaining members of SyntheticModule (ResolveExport and Evaluate). Bug: v8:9292 Change-Id: I25b1b695b5d1c3004677cd685f0dfd95283438fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1626829 Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62433}
-
- 26 Jun, 2019 1 commit
-
-
Sathya Gunasekaran authored
Change-Id: I8e6f10d6a5cba981134b44fda1a8ae3a4ea0fc97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675959 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62371}
-
- 24 Jun, 2019 3 commits
-
-
Dan Elphick authored
Bug: v8:9183 Change-Id: I40c1cd1f55efc353af19cdee48e85ddc8085586c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664059 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#62344}
-
Mathias Bynens authored
We currently use the class name “JSValue” for JSObjects that wrap primitive values. This name is a common source of confusion. This patch switches to a name that’s more clear. In addition to manual tweaks, the patch applies the following mechanical global replacements: before | after --------------------------------|-------------------------------------- if_valueisnotvalue | if_valueisnotwrapper if_valueisvalue | if_valueiswrapper js_value | js_primitive_wrapper JS_VALUE_TYPE | JS_PRIMITIVE_WRAPPER_TYPE JSPrimitiveWrapperType | JSPrimitiveWrapper type jsvalue | js_primitive_wrapper JSValue | JSPrimitiveWrapper _GENERATED_JSVALUE_FIELDS | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#62337}
-
Igor Sheludko authored
... as its existence gives us nothing. Bug: v8:9183 Change-Id: I80234e4ca8b0c9f596a7a3ff79a926d0dda98db8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672937Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62334}
-
- 19 Jun, 2019 2 commits
-
-
Daniel Clark authored
Introduce SourceTextModule as a subclass of Module. Move all the JavaScript-module-specific code down from Module to SourceTextModule, with all code applicable to other future module types remaining in Module. With this change, Module is roughly equivalent to the spec's Abstract Module Record and SourceTextModule is roughly equivalent to Source Text Module Record. Bug: v8:9292 Change-Id: I6e9cd3ece9d0c1da57e52f8af8ed5848d87dd22d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1633154 Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#62296}
-
Igor Sheludko authored
... and add i::GetIsolateFromHeapObject(HeapObject, Isolate*) and i::IsReadOnlyHeapObject(HeapObject) instead. Previously the removed function was also used for checking if given heap object is a read only object. But if pointer compression is enabled the i::GetIsolateFromHeapObject() will succeed for both read only and writable heap objects. Bug: v8:9379, v8:7703 Change-Id: Ib0a9babafe32f43716dac70620b51657dfb97d7c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667416Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62291}
-
- 17 Jun, 2019 1 commit
-
-
Maciej Goszczycki authored
Rename LargeObjectIterator to LargeObjectSpaceObjectIterator. Rename SemiSpaceIterator to SemiSpaceObjectIterator. Rename CombinedHeapIterator to CombinedHeapObjectIterator. Rename ReadOnlyHeapIterator to ReadOnlyHeapObjectIterator. Rename HeapIterator to HeapObjectIterator. Rename HeapObjectIterator to PagedSpaceObjectIterator. Rename PagedSpaces to PagedSpaceIterator. Bug: v8:9183 Change-Id: If4bd65d81e50bb45d207a897baaca8b723e4f10b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645914Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#62217}
-
- 14 Jun, 2019 1 commit
-
-
Daniel Vogelheim authored
This extends the existing Isolate::SetAllowCodeGenerationFromStringsCallback mechanism, by adding SetModifyCodeGenerationFromStringCallback, which can also modify the eval argument (it could e.g. add escaping). Bug: chromium:940927 Change-Id: I2b72ec2e3b77a5a33f428a0db5cef3f9f8ed6ba2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593336Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#62185}
-
- 12 Jun, 2019 2 commits
-
-
Seth Brenith authored
This change adjusts object initialization order for a few classes so that the GC can never see those objects in an invalid, partially- initialized state. AccessorInfo: Just zeros out a few fields upon construction. This is the simplest case. FunctionTemplateInfo: Slightly changes the order in which fields are set, so that the Smi field is set ahead of the call to SetCallHandler, which can GC. Also a pretty simple case. JSListFormat, JSPluralRules, JSRelativeTimeFormat, JSSegmenter: The spec requires that we start with OrdinaryCreateFromConstructor, which has observable side effects (it fetches the prototype from the new.target). So we split JSObject::New in half: the first half does all of the user- visible things and returns a Map, which we can pass to the second half when we're ready to actually allocate the object. JSTypedArray: Extends the pattern from JSListFormat into Torque code: start with a Map and don't allocate the object until we're ready to set all of its properties. Bug: v8:9311 Change-Id: Id7703e8a0727ec756c774cfbb56af787658a111a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646844 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#62123}
-
Benedikt Meurer authored
API calls made via the CallApiCallback builtin, which is used from the ICs and optimized code, are currently misattributed to the wrong counter InvokeFunctionCallback instead of FunctionCallback. In addition we don't use the C trampoline when only runtime call stats are enabled, but the Chrome DevTools profiler is not active, which means that these calls will not be attrituted properly at all, and that had to be worked around using all kinds of tricks (i.e. disabling fast-paths in ICs when RCS is active and not inlining calls/property accesses into optimized code depending on the state of RCS). All of this was really brittle and only due to the fact that the central builtin didn't properly check for RCS (in addition to checking for the CDT profiler). With this fix it's now handled in a central place and attributed to the correct category, so user code doesn't need to worry about RCS anymore and can just call straight into the fast-path. Drive-by-fix: Do the same for AccessorInfo getter calls, which share the core hand-written native code with the API callback logic. Bug: v8:9183 Change-Id: Id0cd99d3dd676635fe3272b67cd76a19a9a9cea4 Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1651470 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62109}
-
- 11 Jun, 2019 1 commit
-
-
Igor Sheludko authored
Tbr: ulan@chromium.org Bug: v8:9353 Change-Id: I99533e21fd186f6d0191f4f500d1a3055a0f92c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648260 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62082}
-
- 06 Jun, 2019 2 commits
-
-
Yang Guo authored
Bug: chromium:965916 Change-Id: I2cb28a8c569c88631bc835b55a04e8629f56cb6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630684Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62034}
-
Ulan Degenbaev authored
The new API function is called ConfigureDefaultsFromHeapSize and accepts two parameters: the initial and the maximum heap size. Based on the given limits the function computes the default size for the young and the old generation. The patch also cleans up the existing functions to make them consistent in terms of units and heap structure. Bug: v8:9306 Change-Id: If2200a9cdb45b0b818a373207efe4e6426f7b688 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631593 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#62017}
-
- 05 Jun, 2019 2 commits
-
-
Ulan Degenbaev authored
This reverts commit ce23fd64. Original change's description: > [heap] Clean up Heap::ConfigureHeap > > This re-arranges the implementation of the function to make it more > consistent. The only functional change is replacement of RoundUp with > RoundDown, which makes more sense for the limits. > > Bug: v8:9306 > Change-Id: Id1d4bc6cc414e3618c3878de8cb87a9ed59711f5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643432 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61997} TBR=mlippautz@chromium.org,jgruber@chromium.org Change-Id: I2352c1305ea3e617b32951e4b1aa871271800478 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645330 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#62008}
-
Maya Lekova authored
This reverts commit f2823886. Reason for revert: Causes TSAN timeouts in RestoreHeapLimit, see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/26812 Original change's description: > [heap] Clean up Heap::ConfigureHeap > > This re-arranges the implementation of the function to make it more > consistent. The only functional change is replacement of RoundUp with > RoundDown, which makes more sense for the limits. > > Bug: v8:9306 > Change-Id: Id1d4bc6cc414e3618c3878de8cb87a9ed59711f5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643432 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61997} TBR=ulan@chromium.org,mlippautz@chromium.org,jgruber@chromium.org Change-Id: I635d60fdfb332cf62ab55eb32242937ebee2f6ad No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9306 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645323Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#61999}
-