- 06 Feb, 2020 11 commits
-
-
Steve Blackburn authored
Simple correction over prior commit since TPH no longer needs to depend on V8 read only heap. Bug: v8:9533 Change-Id: Icc72cdbb58fb3d9dc79573548cd9fe9cc88b2684 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039350Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Steve Blackburn <steveblackburn@google.com> Cr-Commit-Position: refs/heads/master@{#66151}
-
Steve Blackburn authored
These two checks should occur regardless of which allocator we're using, so move them above the TPH check. The check immediately following is V8-specific, so stays where it is. Bug: v8:9533 Change-Id: I127e39969f4aa39ef09ff7b0fdb5ed52b535ad43 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039434Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Clemens Backes authored
The LOAD_RAW and LOAD_RAW_NODE_OFFSET macros just call method on the GraphAssembler now, hence we can remove the macros and just do the calls directly. This reduces code complexity. R=jkummerow@chromium.org, tebbi@chromium.org Bug: v8:10123 Change-Id: I1d779969a14a52256eecb33007564eb190bdcff2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039051 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66149}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/111e7f9..c80cd76 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f72ef2d..1ffa053 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/fff0fe4..e868546 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: If36c8015d0dba083c0bfafd5ee8139bfb1989b19 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041394Reviewed-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@{#66148}
-
Steve Blackburn authored
Bug: v8:9533 Change-Id: I8c8f6d7e2fddae13a9a01a77ac26b1f2ad338889 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039430Reviewed-by:
-
Yu Yin authored
port 59bda196 https://crrev.com/c/2036082 Original Commit Message: This CL adds the "WasmDebugBreak" builtin for x64, ia32, arm and arm64. It stores all wasm parameter registers to the stack and calls the respective runtime function. The runtime function does not do anything yet, but the inspector/debugger/wasm-set-breakpoint-liftoff test will already execute both the builtin and the runtime function. Change-Id: I7e74116f711d9d2599f6f1a6d47b972bad101f8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041214Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Yu Yin <xwafish@gmail.com> Cr-Commit-Position: refs/heads/master@{#66146}
-
Tobias Tebbi authored
- In log.cc, we used InstructionStart() for code create events, but the Code object address for code move events. Change to use InstructionStart() for both. - The symbol table contains some kind of virtual address, not file offsets. They happened to be identical in the past but are no longer, probably due to toolchain changes. Now we use objdump to figure out the difference between virtual addresses and file offsets. - When a new code object happened to be created at the same address as a previous one, we wouldn't update it. This is indeed wrong, as predicted in a TODO by Jaro. - For 64bit addresses, using >>> is wrong, now replaced with division. Change-Id: Ib23114ed736f98bfc33c65004a039a3fd04d3c49 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016586Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66145}
-
Clemens Backes authored
This rewrites the macros to use the GraphAssembler directly. As a next step we should explore if the macros are still worth having, or if they should be inlined everywhere. R=jkummerow@chromium.org Bug: v8:10123 Change-Id: Ia700e00af6a617c4d5a9e34f5be6cab098cd576a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037449Reviewed-by:
-
Yu Yin authored
also correct elf_machine for mips. Change-Id: I261d5bf54ec7ac88290141a4b4ec12e203c34155 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035515 Auto-Submit: Yu Yin <xwafish@gmail.com> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/base/trace_event/common: https://chromium.googlesource.com/chromium/src/base/trace_event/common/+log/bd79231..dab187b Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7dffbb7..111e7f9 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2e4a40a..f72ef2d Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/e931018..fff0fe4 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/847296c..4f24c2a Rolling v8/tools/luci-go: git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711..git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601 Rolling v8/tools/luci-go: git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711..git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601 Rolling v8/tools/luci-go: git_revision:8c17d4a7b01d6257e927c629cc623ebc6a6b3711..git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ib36bbd2f1cb29c461b2aea9a0ed59582a59c94af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2040930Reviewed-by:
-
Clemens Backes authored
This reverts commit 44380f80. Reason for revert: Breaks tsan, msan and ubsan, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/30187 Original change's description: > Fix SEGMAP_ERR by rolling ICU? > > Fix Intl.ListFormat long strings cause SEGMAP_ERR > Add slow regression test. > > Bug: chromium:1044570 > Change-Id: I20e3523832ac3c69e88c11bd530122bbe782ad01 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032712 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66140} TBR=machenbach@chromium.org,ftang@chromium.org,syg@chromium.org Change-Id: I079a675b754b413398d327c44bfeded9c7406333 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1044570 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039355Reviewed-by:
-
- 05 Feb, 2020 18 commits
-
-
Frank Tang authored
Fix Intl.ListFormat long strings cause SEGMAP_ERR Add slow regression test. Bug: chromium:1044570 Change-Id: I20e3523832ac3c69e88c11bd530122bbe782ad01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032712Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#66140}
-
Andreas Haas authored
R=thibaudm@chromium.org Change-Id: I68688e9613a9af4091963175b041df82410bddc4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037446Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#66139}
-
Milad Farazmand authored
Port 59bda196 Original Commit Message: This CL adds the "WasmDebugBreak" builtin for x64, ia32, arm and arm64. It stores all wasm parameter registers to the stack and calls the respective runtime function. The runtime function does not do anything yet, but the inspector/debugger/wasm-set-breakpoint-liftoff test will already execute both the builtin and the runtime function. R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I881a22f1e7c8f9c0714caaa0de75e00177da51e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2038136Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66138}
-
Michael Lippautz authored
Delay completing marking (and thus the atomic GC pause) during JS executions, increasing the chance to finalize the garbage collection from a task. This is beneficial as it avoids stack scanning which is expensive and can keep alive outdated objects in case of unified heap. Completing will be delayed at most by some overshoot factor (10%). In addition, the GC keeps the weighted average of previously recorded time to incremental marking task invocations and bails out if the task is expected to arrive too late. Reland: Do not schedule a delayed task when marking has already been finalized. This reverts commit 1775684e. Bug: chromium:1044630, v8:10178 Change-Id: Ic46e9504ce7c200bd1d37ee8d0190fb8727a3f96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037436Reviewed-by:
-
Clemens Backes authored
This makes the code more readable, and allows for easier future performance optimizations. R=jkummerow@chromium.org Bug: v8:10123, v8:10070 Change-Id: Ifd27f0c888da21bb7f5729c550e8993e793ae7d2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037438Reviewed-by:
-
Georg Neis authored
Bug: v8:10101 Change-Id: If833324b1acebcde8a3bce8888d86c598ed14249 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037442 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
-
Michael Achenbach authored
The bug appears to be fixed. No-Try: true Bug: chromium:693426 Change-Id: Ibd029c906dca87a3fd0c3e00be0b795e87390bd4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037439Reviewed-by:
-
Peter Marshall authored
This reverts commit cf1fad58. Reason for revert: Breaks web tests: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux%20Debug/2684 Original change's description: > [tooling] Keep track of idle state even when we aren't profiling > > It isn't expensive to set this enum on the isolate and we only call > this in chrome when the ThreadDebugger is enabled anyway. > > This means we have a correct idle state to use with the upcoming > CDP event which emits the thread state. > > Bug: chromium:1025490 > Change-Id: Ia555ac8c401d0ad7c72d4cbc442be388ce166131 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036087 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66125} TBR=yangguo@chromium.org,petermarshall@chromium.org Change-Id: I3823197974a2e683364f56819de6ea33dbb8b296 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1025490 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037441Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#66133}
-
Clemens Backes authored
When converting JS values to wasm, we have a fast path for smi inputs. This CL makes this fast path faster by making the alternative (calling ToNumber) deferred. That slow path will be slower then, especially since register allocation (in particular the spilling decisions) are less optimal. Bug: v8:10070 Change-Id: I633a32e85b5a32f490980351b258da8e7a32a9e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037435Reviewed-by:
-
Sathya Gunasekaran authored
The source position is set to the function call (console.log) not the spread (..x), in the bytecode generator, as the spread operation is done as part of the CallWithSpread bytecode. The CallPrinter stops at the function call and doesn't look at the arguments as well (in CallPrinter::VisitCall) to see if the error is from an incorrect spread operation. With this patch, we pass some state to the CallPrinter in the CallWithSpread error case and check that in CallPrinter::VisitCall before returning. For the given source string: ``` x = undefined; console.log(1, ...x); ``` Previously, the error was - ``` test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator)) console.log(1, ...x); ^ TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator)) at test.js:2:9 ``` Now, the error is - ``` _test.js:2: TypeError: x is not iterable (cannot read property undefined) console.log(1, ...x); ^ TypeError: x is not iterable (cannot read property undefined) at _test.js:2:9 ``` Bug: v8:10038 Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431Reviewed-by:Leszek Swirski <leszeks@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#66131}
-
Dan Elphick authored
Fixes the one case after calling EnsureSourcePositionsCollected that we were still using the non-handle version of the SharedFunctionInfo. Bug: chromium:1048555 Change-Id: Iefd35fab13623a1f05212c98864be62c37463942 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037437 Commit-Queue: Dan Elphick <delphick@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66130}
-
Clemens Backes authored
If new Liftoff code is generated but we already have either Liftoff or TurboFan code, we still want to install and use the new Liftoff code if we are in debugging. This logic can probably be simplified again when the "tier down to liftoff on Debugger.enable" logic is fully implemented. I left a TODO to revisit the logic later. R=thibaudm@chromium.org Bug: v8:10147 Change-Id: Ie3a6bdf1cde4f1af884edc8cf1f1b5a507283a5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036089 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
This implements the runtime function for DebugBreak functionality in Liftoff code. We find the Liftoff frame on the stack, get the position within that frame, find breakpoints set at that position, and then call {OnDebugBreak} with these breakpoints. Note that one additional change is needed in order to make this actually hit the right breakpoints. Once everything is in place, we will see a change in the expected output in the wasm-set-breakpoint-liftoff test. R=thibaudm@chromium.org Bug: v8:10147 Change-Id: I5ca569a68aa436bbcf70739ea430efb9e459fad5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036086 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Andreas Haas authored
R=clemensb@chromium.org CC=zhin@chromium.org Bug: v8:10108 Change-Id: I68b81f46166d806ac0bc9bc7cc9ae9fcb4ea6d84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030729Reviewed-by:
-
Clemens Backes authored
This CL adds the "WasmDebugBreak" builtin for x64, ia32, arm and arm64. It stores all wasm parameter registers to the stack and calls the respective runtime function. The runtime function does not do anything yet, but the inspector/debugger/wasm-set-breakpoint-liftoff test will already execute both the builtin and the runtime function. R=thibaudm@chromium.org Bug: v8:10147 Change-Id: I445fdd7c202480ece951f5efbb4845cf21410d91 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036082Reviewed-by:
-
Peter Marshall authored
It isn't expensive to set this enum on the isolate and we only call this in chrome when the ThreadDebugger is enabled anyway. This means we have a correct idle state to use with the upcoming CDP event which emits the thread state. Bug: chromium:1025490 Change-Id: Ia555ac8c401d0ad7c72d4cbc442be388ce166131 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036087Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#66125}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2283658..7dffbb7 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ebf2bec..2e4a40a Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/306f375..10b1902 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/dbd3825..9f40209 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/9ce85c8..847296c TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I28cafd08fccb8d9549717d90c10d7da1948fdb72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035739Reviewed-by:
-
Ng Zhi An authored
These instructions were probably leftover from an earlier cleanup. We can move them into respective macro lists, then delete away the redundant declarations, definitions, disasm, and tests. We were missing disasm tests for SSE2_INSTRUCTION_LIST_SD, so add that in. Change-Id: I8f27beaf57e7a338097690073910a0863f00b26a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036833Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66123}
-
- 04 Feb, 2020 11 commits
-
-
Andreas Haas authored
The instruction selector assumed for Word32AtomicPairCompareExchange nodes that if there exists a Projection(1) user, then there also exists a Projection(0) user. This, however, is not the case, because TurboFan eliminates unreachable nodes. The missing projection node lead to a failed DCHECK in the register allocator. With this CL we allocate the right registers for the existing projections, and allocate the other needed registers as temp registers. R=gdeepti@chromium.org Bug: v8:10140 Change-Id: Id50768c3cb712db5e0eb3b9dcd0a8a479e20953a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030731Reviewed-by:
-
Ng Zhi An authored
The implementation is pretty much the same, and we instead delegate to a macro assembler to decide if we want the sse or avx instruction. This unification will simplify optimization of constant shifts later on. Bug: v8:10115 Change-Id: I68e60cb3fd51156438989812be189f71e6e47ba7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2026470Reviewed-by:
-
Michael Achenbach authored
This reverts commit 02e57873. Reason for revert: High flakiness and broken GPU builders. See: https://crbug.com/v8/10178 (speculative revert) Original change's description: > heap: Delay completing marking > > Delay completing marking (and thus the atomic GC pause) during JS > executions, increasing the chance to finalize the garbage collection > from a task. This is beneficial as it avoids stack scanning which is > expensive and can keep alive outdated objects in case of unified heap. > > Completing will be delayed at most by some overshoot factor (10%). > > In addition, the GC keeps the weighted average of previously recorded > time to incremental marking task invocations and bails out if the > task is expected to arrive too late. > > Bug: chromium:1044630 > Change-Id: I10e63e6aaa88d8488d4415f311016dce2b4e62a2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030906 > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66107} TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org Change-Id: I0cd3f1189d0f83754350d5bdaaf82cb3c4d402c8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1044630, v8:10178 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037434Reviewed-by:
-
Ng Zhi An authored
This relands commit 5cfe053e. Original change's description: > [wasm-simd][liftoff] Add S128 case for stack movements > > The two cases we are fixing here are Construct and > LoadCallerFrameSlot, which are closely related. > > Construct is called during PrepareCall, where we build up > LiftoffStackSlots when we need to move an arg from caller's stack frame > into callee's stack frame. LoadCallerFrameSlot is the parallel to > this, called in ProcessParameter during decoding of the callee's > function body. > > In most cases, Construct needs a new case to handle kWasmS128, and calls > the relevant assembler to push a s128 onto the stack. > > ARM64 requires 16-byte alignment of sp, so we need to Claim the right > number of kXRegSize slots first, which requires > us traversing the list of slots to figure out how many s128 values there > are. This is a straightforward way to fix this, if efficiency is a > problem, we can change LiftOffStackSlots::Add to sum up the slot sizes. > > On IA32, pushing s128 values will require 4 calls to push. Instead, we > use a sub and two movdqu, which will generate less code in most cases. > > On x64, there is no 128-bit push, so we call push twice. > > Bug: v8:9909 > Change-Id: I3af35b8462ea9c3b9b2d90800c37d11b5e95be59 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015945 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65956} Bug: v8:9909 Change-Id: Icdaead289abe13faf75bb9e049929f7fd7c59a08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036760 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
This is a reland of 45ea0150 Original change's description: > [wasm] Use memcmp to compare module bytes > > This is much faster than std::lexicographical_compare. > > R=clemensb@chromium.org > > Bug: chromium:1048554 > Change-Id: I5f0ba22654e172535b6e6fcf6d2a460e278d3cfd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036078 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66109} Bug: chromium:1048554 Change-Id: I04d4b1ea8354f7d0567100dec10be0de6ca0ed37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037432 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Thibaud Michaud authored
Ensure that the top tier streaming callback is called, even when the native module is actually fetched from the cache rather than compiled. This preserves the old behavior, such that the cache stays an implementation detail to clients of the streaming compilation API. R=clemensb@chromium.org Bug: v8:10165 Change-Id: Ib243c97529900f76b7b9cd5d1d57f259bc38225c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035875 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Johannes Henkel authored
"Remove the JSON parser and revamp Value::parseBinary." Upstream review: https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2026351 In addition to the upstream changes, this PR includes the necessary tweaks to the V8 inspector (now taking the detour via CBOR to parse Javascript). New Revision: 0e0a1995497511008864546c094e885f3f1e13a3 Change-Id: I5ccfea5a3e1bab3e183b45c87726747d17d06944 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020518Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66116}
-
Michael Lippautz authored
When not being embedded, there's no need to try to share time with the embedder. Additionally, avoid too small step sizes. Bug: chromium:1044630, chromium:1048631 Change-Id: I227bfd120b5ce1976935d27c2140263f7364eb51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036085 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Michael Achenbach authored
This will allow uploading repro test cases to clusterfuzz for already suppressed known issues. This will allow tracking if those issues still reproduce and that suppressions don't become stale. No-Try: true Bug: chromium:1044942 Change-Id: I997f11293c51836b97d143b0fea992055b39955e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036083 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Liviu Rau <liviurau@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#66114}
-
Steve Blackburn authored
Change the TPH API so that it uses v8::internal::Isolate rather than v8::isolate. The third party heap is within the internal namespace and ultimately needs access to v8::internal::Isolate to do things such as adding code ranges. There's no reason for it to use v8:Isolate. Bug: v8:9533 Change-Id: I8c3ecd6278081f03133013d4e3b02fb3ed228baf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036088Reviewed-by:
-
Michael Achenbach authored
No-Try: true Bug: chromium:1048620 Change-Id: I399144a9d8075efe40125dfcbe1dbbd0aabe0fe9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036080Reviewed-by:
Mathias Bynens <mathias@chromium.org> Reviewed-by:
-
