This CL adds a table to the right side of the each
timeline-tracks to display statistics about the log
events. Double clicking on an event type notifies other
panels about the selected log events with the selected type.
Bug: v8:10644
Change-Id: Iae523d46da4f0b6a007b02a2beac23d9c48aca02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2353457
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69498}
This is a reland of ad68de6f5b
Reason for reland: Reverted since another CL got reverted. This cleanup
is independent though and can be relanded.
Original changes description:
> [compiler] Remove unused holder parameter from IF_ACCESS_FROM_HEAP(_C)
>
> Bug: v8:7790
> Change-Id: I44849f45d1049b8a3c794dd0558b734c1e7061fd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362919
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69482}
Bug: v8:7790
Change-Id: Ib650ef1701168be7a910ff51e30a90e239d5f5c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366774
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69496}
With concurrent allocation background threads invoke Log::IsEnabled()
as well. Fix data race here by making is_enabled_ atomic, such that
IsEnabled() remains cheap.
After locking the mutex in MessageBuilder, IsEnabled() needs to be
checked again in case an old value was read. Otherwise we might log
even though logging was already disabled on another thread.
The other direction where a log message isn't logged is deemed
acceptable.
Bug: v8:10315
Change-Id: I32c9dd2e9879fbdb4ca94e080a16ddd875de7c30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362948
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69495}
Load extends always load 8 bytes, so the access size does not depend on
MachineType of the load. The MachineType is used for classifying the
lane shape of the 8-byte load.
Also add cctest to load splats and load extends to test OOB. (Note that
load splats access size depends on MachineType).
Add regression test from clusterfuzz, minimized by ahaas@. Remove the
`--no-wasm-trap-handler` flag since we have a no_wasm_traps variant that
should test this flag.
Bug: chromium:1116019
Change-Id: I27ba051d0536ca0f6fd75dd641ca9b78132dafed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363291
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69489}
CanonicalHandleScope is now also used on background threads. Therefore
Heap::RegisterStrongRoots and Heap::UnregisterStrongRoots are not
exclusively used on the main thread anymore. Simply protect this list
with a mutex.
Bug: v8:10315, v8:10814
Change-Id: Id08269c9f7fecae8c570ab711c522d111b06b005
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364503
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69488}
This reverts commit 7b9a0c20f3.
Reason for revert: Different tests start flaking, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/29532
Original change's description:
> [compiler] Replace ScopeInfoData with direct reads
>
> As part of this, introduce a new ObjectData kind for objects that we
> want to read directly from the background thread rather than serialize.
> ScopeInfoRef is the first user of that.
>
> For details, see:
> https://docs.google.com/document/d/1U6x6Q2bpylfxS55nxSe17yyBW0bQG-ycoBhVA82VmS0/edit?usp=sharing
>
> Bug: v8:7790
> Change-Id: Ia3cda4f67d3922367afa4a5da2aeaae7160cf1f2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346405
> Auto-Submit: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69473}
TBR=neis@chromium.org,solanes@chromium.org,nicohartmann@chromium.org
Change-Id: Ide5a4a583547b63cc9accfb93fcadb97b8100e8a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364504
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69487}
The number of constants stored in locals and the merge region can be
arbitrarily big, thus generating arbitrarily long code for a single
`br_if`. This happened in particular for unoptimized code.
This CL solves this by materializing all constants (in registers or on
the stack) before doing a conditional branch. This ensures that in a
series of `br_if`s, each constant is only spilled once instead of on
each single branch.
For the linked bug, this reduces the total generated code size by ~36%.
R=thibaudm@chromium.org
Bug: chromium:1117033
Change-Id: I84ea2ea9ba4d3de9b042ceb223af15c3d73dc5b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2364498
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69485}
This is part two of the implementation (part 1: heuristics in NCI code
to call the runtime profiler, part 2: heuristics in the runtime
profiler to mark the function for optimization, part 3: the final
part, recognizing and acting upon the marked function).
The runtime profiler heuristics added here remain very similar to what
we have for ignition, except that we now inspect optimized frames with
NCI code, and that we (currently) do not OSR from NCI to TF.
Bug: v8:8888
Change-Id: Ie88b0a0dcee16334cea585c771a4b505035f2291
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358748
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69484}
Drive-by: Remove a parameter that had to be SKIP_WRITE_BARRIER.
Bug: v8:9708, v8:6949
Change-Id: Ib5d0521f255a92749440a5001dab8b59eb078bf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362950
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69481}
This CL adds a basic implementation of incremental marking for standalone GC.
Followup CLs include:
* Use bytes instead of time as deadline
* Port incremental marking schedule from blink
* Mark on allocation
* Guarantees for progres/termination for standalone GC
* etc...
Calling StartIncrementalGarbageCollection triggers StartMarking which
schedules incremental marking as non-nestable tasks.
For unified heap, marking will continue running until it runs out of
work but it won't finalize independently.
For standalone, when incremental runs out of work it will schedule a new
task in which it will finalize marking and trigger the rest of the GC.
Users of standalone can also force finalization before incremental
marking as finished using FinalizeIncrementalGarbageCollectionIfRunning.
Calling CollectGarbage would also finalize an on-going incremental GC
if one exists. Otherwise it will trigger an atomic GC.
See the following doc for explanation of the various methods:
https://docs.google.com/document/d/1ZhJY2fOoD8sH53ZxMh2927Zl8sXqA7azJgcQTWx-YKs/edit?usp=sharing
Bug: chromium:1056170
Change-Id: I75ead414eb9da9f8b7f71c4638b9830fce7708ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298009
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69480}
When CFI is enabled this adds a check against this list whenever a new
return address must be set in a deoptimized frame, as a mitigation for
ROP attacks.
The list is known at linking time so that its content and the pointer
to it can be stored in a read-only memory section.
The check is performed in the signing function, which is no longer
generic, as well as when setting the current pc of the frame.
Since the pc is now only signed when setting the caller's pc, there
is no need for ReplaceContext anymore.
Bug: v8:10026
Change-Id: I5e85a62b94722051716fdeba476db383c702a318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287490
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Cr-Commit-Position: refs/heads/master@{#69478}
When running with --verify-heap, ObjectVerify() is invoked for every
live object anyway, so there is no need for individual FooVerify()
implementations to recursively request verification of their
sub-objects. If they do, (a) it is duplicated work of O(n²) complexity,
and (b) it can cause fuzzer-generated tests to crash because they run
out of stack space when they trigger heap verification with very little
stack space left.
Fixed: chromium:1106426
Change-Id: Ib9bd444806b148fffc23d635f931dfe73fe7e4ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358746
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69477}
As part of this, introduce a new ObjectData kind for objects that we
want to read directly from the background thread rather than serialize.
ScopeInfoRef is the first user of that.
For details, see:
https://docs.google.com/document/d/1U6x6Q2bpylfxS55nxSe17yyBW0bQG-ycoBhVA82VmS0/edit?usp=sharing
Bug: v8:7790
Change-Id: Ia3cda4f67d3922367afa4a5da2aeaae7160cf1f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346405
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69473}
We can create a new macro to skip the xxxData classes and read directly
from the heap.
Bug: v8:7790
Change-Id: I8de9ba0aee78c74d4c3113eb6bc4870a314de552
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362687
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69471}
Add an event for recording metrics related to compiling Wasm modules.
This provides different events for both baseline compilation and
tier-up.
R=clemensb@chromium.org
Bug: chromium:1092417
Change-Id: Ib5ea7f5ba9e91e2c34473e666eea1c6dc6a97037
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351674
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69470}
... to avoid the repeated pattern of calculating it.
Bug: v8:8888
Change-Id: I4af5264aae6cfb8b6232b5aaf9ceb2cb568c29d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362692
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69469}
The V8 wasm fuzzer can create regression tests for failing fuzzer cases.
These regression tests use the wasm-module-builder.js. With the addition
of simd to the wasm-compile-fuzzer, the fuzzer can now create test cases
that use simd instructions, but the wasm-module-builder.js did not know
yet about the new instructions. This CL adds some instructions to
wasm-module-builder.js.
R=zhin@chromium.org
Bug: chromium:1116019
Change-Id: I198e4f11c2225a65d6b438f95e351fc14ee66218
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362694
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69467}
Port 2547e1cece
Original Commit Message:
Since the compilation progress was never initialized on deserialization,
tier down was always skipped on such modules.
By initializing to the expected state after deserialization (i.e. all
code as TurboFan code), we make sure that later recompilation works as
expected.
R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Iab66ca0d1bfb36cfee56ccd85720d4c5552eb9c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363270
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69465}
Instead of returning a boolean value on {WasmCodeManager::Commit}, and
always failing on {false}, just remove the return value and fail within
{WasmCodeManager::Commit} directly. This allows us to generate better
error messages if running OOM.
R=thibaudm@chromium.org
Bug: chromium:1107649, chromium:1117033
Change-Id: Ic8089e4385ddf92c164b9a0c770c210e1caddcbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362962
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69464}
Prior versions of GN had a bug (gn:22) where visibility rules
for configs weren't being enforced properly.
This CL tweaks the visibility settings of some configs to
conform to the latest version.
Change-Id: Ic5d827a1f2774278d3894f67fe52bfca836c0409
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360909
Commit-Queue: Dirk Pranke <dpranke@google.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69463}
There exists such optimization for additions but not for multiplication.
This adds optimizations that apply the reductions
(x * Int32Constant(a)) * Int32Constant(b)) => x * Int32Constant(a * b)
(x * Int64Constant(a)) * Int64Constant(b)) => x * Int64Constant(a * b)
to the TurboFan graph.
Bug: v8:10305
Change-Id: I28f72c2b7d8ff0f758a0a08b69fb3763557a6241
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360327
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69462}
Port 360c9294a8
Original Commit Message:
In Liftoff, we were missing kS128 cases to load to/from stack.
For the x64 and ARM64 instruction selector, the calculation of
reverse_slot is incorrect for 128-bit values:
- reverse_slot += 2 (size of 128-bit values, 2 pointers)
- this copies from slot -2 into register
- but the value starts at slot -1, it occupies slots -1 and -2
- we end up copying slot -2 (most significant half) of the register, and
also slot -3, which is where rsi was store (Wasm instance addr)
- the test ends up with a different result every time
The calculation of reverse_slot is changed to follow how ia32 and ARM
does it, which is to start with
- reverse_slot = 0
- in the code-generator, add 1 to the slot
- then after emitting Peek operation, reverse_slot += 2
The fixes for x64 and ARM64 are in both instruction-selector and
code-generator.
ia32 and ARM didn't support writing kSimd128 values yet, it was only a
missing check in code-generator, so add that in.
For ARM, the codegen is more involved, vld1 does not support addressing
with an offset, so we have to do the addition into a scratch register.
Also adding a test for returning multiple v128. V128 is not exposed to
JavaScript, so we use a Wasm function call, and then an involved chain
of extract lanes, returning 6 i32 which we verify the values of. It
extracts the first and last lane of the i32x4 value in order to catch
bugs where we write or read to a wrong stack slot (off by 1).
The simd-scalar-lowering for kCall was only handling single s128 return,
we adopt the way i64-lowering handles kCall, so that is can now handle
any kinds of calls with s128 in the descriptor.
R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I1ad9595d7820f04687c9d79941ad04c6eb207897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363118
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69461}
Since the compilation progress was never initialized on deserialization,
tier down was always skipped on such modules.
By initializing to the expected state after deserialization (i.e. all
code as TurboFan code), we make sure that later recompilation works as
expected.
Drive-by: Fix an unnecessary copy of a {shared_ptr} in deserialization.
R=thibaudm@chromium.org
Bug: chromium:1110258
Change-Id: Ia12af888e4b11aabfb8cd4e1201e9fa3cd2ceb47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323355
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69458}
In some objects, the length field for an indexed field might itself be
conditionally included depending on some previous field's value. The
module-related stuff at the end of ScopeInfo is a good example. Torque
can represent that case, with a minor change allowing indexed field
access from within the length expression for another indexed field.
Bug: v8:7793
Change-Id: I9ff5c9cea2b9423f28004beba05a9a24b22c8e3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2360328
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#69457}
Port 4765c70fa6
Original Commit Message:
On arm, the root register points into the middle of the roots array to
allow to use the full int12_t offset range. Therefore some offsets into
the root array are negative. This CL changes the liftoff assembler for
arm to allow loads from negative offsets.
On arm64, offsets can also be negative when pointer compression is
disabled.
Additionally this CL changes the signature of
LiftoffAssembler::LoadTaggedPointer from uint32_t to int32_t to allow
the LiftoffCompiler to provide negative indices.
This CL does not come with a separate test yet. However, this changes is
needed for https://crrev.com/c/2352784. Where there will also be a test.
R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ie286b0169a5f7a1de90e0ec7002bfac83383ea6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2363127
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69456}
The wasm instance is not needed after calling the wasm function.
Bug: v8:10701
Change-Id: I9b53ecba74873746ee9c163011bca0167969c6c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362691
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69454}
On arm, the root register points into the middle of the roots array to
allow to use the full int12_t offset range. Therefore some offsets into
the root array are negative. This CL changes the liftoff assembler for
arm to allow loads from negative offsets.
On arm64, offsets can also be negative when pointer compression is
disabled.
Additionally this CL changes the signature of
LiftoffAssembler::LoadTaggedPointer from uint32_t to int32_t to allow
the LiftoffCompiler to provide negative indices.
This CL does not come with a separate test yet. However, this changes is
needed for https://crrev.com/c/2352784. Where there will also be a test.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I0a97a62ff8e934d45a4494adfbc74a3e1149c8c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2359429
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69453}
This reverts commit 1dd7f3a953.
Reason for revert: Breaks TSAN - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32846?
Original change's description:
> [heap] Add concurrent marking write barrier
>
> A LocalHeap creates and owns an instance of MarkingBarrier. A pointer to
> the marking barrier is set to a thread_local variable for a quick access.
>
> WriteBarrier::MarkingSlow fetches the thread_local variable and invokes
> the write barrier if it is set. Otherwise, it invokes the main thread
> heap()->marking_barrier().
>
> Each marking barrier has its own local marking worklist that is
> published during scavenge (for updating pointers) and at finalization
> of incremental marking.
>
> Typed-slot recording does not work yet because it is not thread-safe.
> It will be fixed in a subsequent CL.
>
> Bug: v8:10315
> Change-Id: I221a906436cd91e7405a253ce0eb06cf68046f2c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354809
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69448}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: I9719d565aaa313cd23f5e759dcef1246f475eb46
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362689
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69451}
MSVC on x86 has issues with ALIGNAS(8) on InstructionOperand,
but does align the object to 8 bytes anyway. As a work-around,
avoid ALIGNAS for InstructionOperand on MSVC x86.
BUG=v8:10796
Change-Id: Iabb465489d97f9518a4429e8d78c06296539ed97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358680
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69450}
{NativeModuleDeserializer::ReadCode} always returned {true}. Thus remove
this return value and the code handling a {false} return.
R=thibaudm@chromium.org
Bug: chromium:1110258
Change-Id: I2cf76936f6eea213e6318ea35bdb58b2ded801c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352782
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69449}
