- 21 Jan, 2020 2 commits
-
-
Tobias Nießen authored
The previous behavior failed silently if the file could not be opened in the first place, and only wrote to stderr if writing failed after opening the file successfully. Change-Id: I1d1058134efd9298b60b65191ed6334de24d3f52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1972886Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65875}
-
Jakob Gruber authored
The most interesting part of this change is that try-catch patterns are now supported by graph assembler through TryCatchBuilder0. Bug: v8:9972 Change-Id: I6ef0d51d4a1973eb8a30a5072c630261860f0a05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986000 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65874}
-
- 20 Jan, 2020 15 commits
-
-
Wez authored
Most V8 unit tests are multi-threaded, so configure GTest to use the thread-safe GTest implementation by default. This can be overridden on a per-test basis by setting: testing::FLAGS_gtest_death_test_style = "fast"; during the test's SetUp() (see the GTest documentation for details). Bug: v8:10143 Change-Id: I7414c5d8ae22eb8d9b8c4813f958ca571e1d0310 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011085 Commit-Queue: Wez <wez@chromium.org> Auto-Submit: Wez <wez@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65873}
-
Wez authored
The SequentialUnmapperTest replaces the process-global PageAllocator with a wrapper which tracks allocations. The suite was deleting the tracking allocator without first restoring the original PageAllocator, causing any subsequent tests which tried to use it to use-after-free. Bug: chromium:934932 Change-Id: I0f69b6a07542a3f381724afdbfb2e9b67a9f39de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010113 Commit-Queue: Wez <wez@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Auto-Submit: Wez <wez@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65872}
-
Georg Neis authored
The verifier tried to assert that the context input of Create*Context nodes has type OtherInternal (all Context constants have that type). This didn't quite work because of OSR values so actually it checked something much weaker. And what it checked still doesn't work because of dead code, in which the context input might statically be known to be the undefined value. I'm removing the assertion entirely now. I suspect that there are other assertions in the verifier that don't hold in the OSR code or in dead code. We are discussing a more general solution such as inserting TypeGuards in the relevant cases. Bug: chromium:1037771 Change-Id: I6fb59c60e7120d5984ea0fe140269f2df6de8708 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010792 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65871}
-
Georg Neis authored
Change-Id: Icc86a805d1eef8c3c805f956d805c43923e6422b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007504 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65870}
-
Z Nguyen-Huu authored
Existing Torque code uses bounds-checked access and it seems to hurt perf. Change to use UnsafeLoadFixedArrayElement. Bug: chromium:1028605 Change-Id: Ifcf3b9d181b4ec0ed1b757eeed466b0f76808578 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007894 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65869}
-
Clemens Backes authored
I hit this issue in an unrelated CL and it took me a while to figure out what's happening. This CL will allow the creation of constant OwnedVectors via {OwnedVector<const T>::Of(collection)}. R=tebbi@chromium.org Change-Id: I337077a6c3960a2a2a8d857bec7450f664b87a3b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010109Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65868}
-
Santiago Aboy Solanes authored
In the case of having: * NodeA(...) * NodeB(NodeA, NodeA), with this being the only use of NodeA. this CL gives A's ownership to B. Before, we used to say that B didn't have ownership of A due to A having two uses. This brings it in line with OwnedBy with two owners check: https://source.chromium.org/chromium/_/chromium/v8/v8.git/+/abd1a0fc04476bbb27ef2dfda2e444cc1467f5f6:src/compiler/node.cc;l=291 Change-Id: I15fdf373136a21bf423e6dffd9588054fd720d72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007502Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65867}
-
Mythri A authored
When bytecode is flushed we also want to flush the feedback vectors to save memory. There was a bug in this code and we flushed ClosureFeedbackCellArray too. Flushing ClosureFeedbackCellArrays causes the closures created by this function before and after the bytecode flush to have different feedback cells and hence different feedback vectors. This cl fixes it so we only flush feedback vectors on a bytecode flush. Also this cl pretenures ClosureFeedbackCellArrays. Only FeedbackCells and FeedbackVectors can contain ClosureFeedbackCellArrays which are pretenured, so it is better to pretenure ClosureFeedbackCellArrays as well. Bug: chromium:1031479 Change-Id: I7831441a95420b9e5711f4143461f1eb7fa1616a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980582 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#65866}
-
Maya Lekova authored
Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/81c050f..e327c63 Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1bee638..fd02540 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/1f38b43..73414d5 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f7d73bb..251c765 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/2a04803..05b001c Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/5395345..306f375 Bug: chromium:1043117 Change-Id: Iee06baa8c4caaed2a187390eeb3c8f0b61db63d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2006669 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#65865}
-
Sigurd Schneider authored
This CL adds a new event that enables the back-end to send coverage updates on its own initiative. This event can be triggered via the C++ method `triggerPreciseCoverageDeltaUpdate` on the agent in a way that causes coverage data to be immediatelly collected. This is useful in the back-end to collect coverage at a certain point in time, i.e. when a lifecycle event such as first contentful paint occurs. The previous interface could not support this, because it could not reasonably be triggered from C++, and if triggered through the protocol, dispatching messages added delay that invalidated the data (i.e. data might have been taken too late to be accurate). TBR=yangguo@chromium.org Change-Id: I0f7201412a8d64866e6e314e5bc850354c13a9da Bug: chromium:1022031 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992437 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65864}
-
Nico Hartmann authored
Bug: chromium:1043117 Change-Id: I0abb11d25852e6f9e62b790dc39a36f11a8fe12f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007503Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65863}
-
Emanuel Ziegler authored
This adjusts parsing of negative numbers in UnaryExpression and MultiplicativeExpression to return double if the token is -0. R=clemensb@chromium.org TEST=mjsunit/regress/regress-6838-4 BUG=v8:6838 Change-Id: I6c2113b520c3831f4a5101f0a963f49c1eb9d7d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007272Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/master@{#65862}
-
Jakob Gruber authored
The loop peeling optimization requires all loop exits to be marked with {LoopExit,LoopExitEffect,LoopExitValue} nodes in order to peel the first loop iteration. Previously, the graph assembler only marked the default loop exit (taken once the loop condition evaluates to false). This CL adds more general support, such that all exits taken inside the loop body passed to a ForBuilder are automatically marked. We do this by tracking the current loop nesting level and a stack of loop headers inside the graph assembler, and creating marker nodes as needed inside MergeState. Bug: v8:9972,chromium:1038297 Change-Id: I1d0196ead55d6678880f8330c7cc7b8d4f2cea06 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000740 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65861}
-
Daniel Clifford authored
The aggregate type finalization loop in the Type Oracle can cause new types to be added to the type list during finalization, invalidating the iterator used in the container-iterating "for" loop. To fix this, visit using an explicit index rather than using a iterator-based for loop. Change-Id: I2fb486043c946a492d972f1e942e3b5e331a1cea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007499 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65860}
-
Nico Hartmann authored
Bug: chromium:1043117 Change-Id: I09faf069e787ae3c5ecc0fd38b4bb55d51f10acf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007501 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65859}
-
- 19 Jan, 2020 3 commits
-
-
Michael Lippautz authored
- Fix copying of already initialized nodes - Add better verification - Add tests for moving/copying onto already initialized nodes Bug: chromium:1040038 Change-Id: I0c144fcfe980d7542cf6803e4dc861e3fd4ca708 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007278Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#65858}
-
Ulan Degenbaev authored
Currently the object is freed in the destructor of Heap but that is too late because the global handles that are used by the object have been destroyed. This fixes a bug that was introduced in 802420. Bug: chromium:1043530,chromium:1043535 Tbr: dinfuehr@chromium.org Change-Id: I980da7b499f1c853ca41a4ef28d02a1f403d4eeb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010104 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65857}
-
Ulan Degenbaev authored
This adds a new API function that can be customized by the embedder by providing a delegate that defines contexts to be measured and reports the results to JS. A memory measurement request is carried out as follows: 1) MeasureMemory(delegate) invocation enqueues a new request in MemoryMeasurement::received_ and schedules a delayed GC task. 2) At the start of the next GC (that is triggered either by the GC schedule or by the delayed task) each request in received_ moves to processing_. Per-context marking worklists are created for each native context that was selected by the delegates (using the ShouldMeasure predicate). 3) At the end of the GC the sizes of the native contexts are recorded for each request in processing_. The requests move to the done_ list and result reporting task is scheduled. 4) When the result reporting task runs it invokes the MeasurementComplete function of each delegate in done_. Bug: chromium:973627 Change-Id: I0254cae693c5b8fab7c85a9eca0a3a128210b6c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981493 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#65856}
-
- 18 Jan, 2020 1 commit
-
-
Adam Klein authored
I'm not actively reviewing parser or API changes these days, so these watchlists aren't really helping anyone. Change-Id: I7babfeabf0f2bff914e7ab03d1f875e57a10ce47 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2008399 Auto-Submit: Adam Klein <adamk@chromium.org> Reviewed-by: Ben Smith <binji@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#65855}
-
- 17 Jan, 2020 19 commits
-
-
Johannes Henkel authored
This adds a DCHECK into v8-inspector-session-impl.cc, covering what we previously checked within ConvertCBORToJSON. Upstream reviews: "Separate the lightweight check for CBOR messages from ParseCBOR." https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2001536 "Remove Exported::writeBinary." https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2005797 New Rev: ac6919eb836521a96cc18931f0bf270d8c1b53a1 Change-Id: I52076a8f77b27c24c3afb35c40afbbe94e0ca05c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002935Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#65854}
-
Santiago Aboy Solanes authored
They were disabled when enabling pointer compression due to a bug (See v8:9568), and they were never re-enabled. Fixes: v8:9568 Bug: v8:9568, v8:7703 Change-Id: I3918ec57726ab9a7f943ab8506636cc95c376c20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007496 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65853}
-
Milad Farazmand authored
Port aa12b60b R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I7844b3f356d7f9f0ad1688880bd1f3420438e181 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007899Reviewed-by: Zhi An Ng <zhin@chromium.org> Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#65852}
-
Ross McIlroy authored
One remaining Node* remains in EmitElementStore which will need to wait for templated versions of StoreElement. BUG=v8:10021 Change-Id: I6422b8dbfd1989cfc7587c2b180e542fbdb56382 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007271Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#65851}
-
Milad Farazmand authored
Port 9ff2de44 R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Iadbdd2ae87ac4b37b36ed5fac14777e48133437e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2008180Reviewed-by: Zhi An Ng <zhin@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#65850}
-
Ng Zhi An authored
Bug: v8:10082 Change-Id: I745cb99ba12d4e8c0ecd9a89bfa596f1bc1f9597 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980835 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#65849}
-
Ng Zhi An authored
Add a cctest to verify correct treatment of functions which return SIMD. This exercises the MoveToReturnRegisters logic, where we need to add a new case for fp pairs. FinishCall also needs to handle fp pairs. Small cleanup to rename needs_reg_pair to needs_gp_reg_pair to be clear, and add a new helper needs_fp_reg_pair. Drive-by fix for cctest to assert that the tests are compiled with Liftoff. Bug: v8:9909 Change-Id: I0cd7a1a90e97372ea85e7668f2298d4fa2d76f4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2006021 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65848}
-
Ulan Degenbaev authored
The function can be invoked in a background task and has to take the page mutex to sweep it. Bug: chromium:1040700 Change-Id: I552fd636ca62f45496dc6c663a0a12d428eb2e20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007273Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65847}
-
Ng Zhi An authored
Bug: v8:9813 Change-Id: I0436c6a90284559a110e99476c12ae39183c961e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994382 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65846}
-
Ng Zhi An authored
This is useful when generating mjsunit tests from the fuzzer, since without the prefix bytes, the opcodes are invalid. This affects the json output for tracing turbofan, so the source view in turbolizer will see this prefix as well. Change-Id: Icd112e0d140c13f96530797da721650201e00660 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2006392Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#65845}
-
Steve Blackburn authored
Bug: v8:9533 Change-Id: I09a929839ca5cbad3f1a3154c6f143b242095ffa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995276Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Steve Blackburn <steveblackburn@google.com> Cr-Commit-Position: refs/heads/master@{#65844}
-
Steve Blackburn authored
Bug: v8:9533 Change-Id: I11ae71b552d2ba96606e99261092d99dc92e680f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995266 Commit-Queue: Steve Blackburn <steveblackburn@google.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65843}
-
Dominik Inführ authored
Split the linked list of array buffer extensions into two lists for young and old JSArrayBuffers. Process young extensions during the minor GC pause. When promoting JSArrayBuffers into the old gen, move the extension into the old linked list as well. Bug: v8:10064 Change-Id: I07275ffe7ba918c9b2d6d0648a6d1b59e4fa4891 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997438 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65842}
-
Michael Lippautz authored
Similar to TracedReference, support TracedGlobal on stack as well. Bug: chromium:1040038 Change-Id: If3400a2df8b4a11410032bd5ad1b7bed64063b93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2005071 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65841}
-
Peter Marshall authored
This was written before lazy feedback vectors and expects that the feedback vector is always present. Instead just return undefined and do nothing if there is no feedback vector. Change-Id: I1ffddd672576cb794eda2d5922b574a8be65d579 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007492Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#65840}
-
Michael Achenbach authored
The contructor arguments were omitted for Android in a previous CL, which broke the Android builder. TBR=tmrts@chromium.org Bug: v8:8292 Change-Id: I266826e2531ba421161d6cd2241eae34b07e7521 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007494Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65839}
-
Georgia Kouveli authored
Memory access offsets are unsigned. Sign-extending them incorrectly treats some large offsets as negative numbers and results in out-of-bounds errors for in-bounds accesses. This caused a failure in test/mjsunit/wasm/huge-memory.js for arm64, and for x64 with --nowasm_trap_handler. Change-Id: If58fead1d115f16ba4a6c3680252111fba6843d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002821 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65838}
-
Michael Achenbach authored
This prints the same details about a process when attempting to kill it as when termination fails with an exception. This will make it easier to correlate the two and to see which might be hanging. Bug: v8:8292 Change-Id: I4b6a50386d4e9d84ded55cf262f19529138654a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2006092Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65837}
-
Jakob Kummerow authored
Not just the large virtual allocation but *all* memory operations should handle resource exhaustion gracefully. Bug: chromium:1042943 Change-Id: I8d36a3d7fa267b588b35b927172bfe56f64fffd2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007489 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65836}
-