Instead of compiling a function with baseline immediately when the
interrupt budget is hit, we compile functions in batches to save some
memory protection flips on code pages.
This CL introduces batch compilation behind --baseline-batch-compilation
(enabled on future) and adds a flag
--baseline-batch-compilation-threshold to control the size of batches.
Bug: v8:11790
Change-Id: I3efc360424a14e4b07c6570e48860509ae59e591
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891656
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74913}
- Maintain the correct stack in unreachable code for all type casts.
- Compute the correct type for the pushed stack value for ref.cast.
- Check if current_code_reachable_and_ok_ instead of checking the
popped values' types against bottom.
- Add unit tests.
Bug: v8:7748
Change-Id: I02c26f526060f40884c4ff1e541315f71d8ad90a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928191
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74912}
After https://crrev.com/c/2910080 we can define the histogram as a
proper boolean histogram with minimum 0, maximum 1, and 2 buckets.
This will map to a chromium histogram with maximum 2, and 3 buckets, but
that conversion will happen on chromium's side.
R=jkummerow@chromium.org
Bug: chromium:1207318
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Change-Id: I176cf2467949591bcc3aa5ad0635cb8b12f20e9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930479
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74911}
os.system seems to be flaky on certain bots. Disabling this until we
have a proper fix.
Change-Id: I075542772ba8eb968c96942923f76b87a2f18d47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2931809
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74910}
This interface allows associating meta information to
exceptions. This meta information can be used by debugging
tools, like DevTools, to learn about e.g. a network request
or a DevTools issue that is associated with the exception.
To do so the inspector client (i.e. embedder) has to provide
the data.
Bug: chromium:1213393
Change-Id: Ia86221f4f04b21024d592bafb2f74886ead8a6a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928496
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74909}
Similar to https://crrev.com/c/2912786, this fixes a high number of
page permission switches (incuring mprotect syscall and lock contention
overhead) by pulling a {NativeModuleModificationScope} outside of a
loop (and across a function boundary).
R=clemensb@chromium.org
CC=jkummerow@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:11663, chromium:932033
Change-Id: I2ec47f3eeeb2ab9624d2eaea9b4e776738871c97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928504
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#74906}
This fixes a bug introduced in crrev.com/c/2717308. For JSArray
holders, we must observe JSArray::length for bounds checks (in
addition to elements.length).
JSArray::length cannot reliably be read from the background thread;
thus we do a best-effort read there, and verify the result during
finalization through a new ArrayIndexIsInBoundsDependency.
Bug: v8:7790,chromium:1209444
Change-Id: I189df9f58043411ada62f32fe741d4729874d357
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928509
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74904}
This reverts commit 59d58d722e.
Reason for revert: This CL breaks --predictable
Original change's description:
> [csa] Remove InnerAllocate and replace with non-folded allocations
>
> This CL removes all uses of InnerAllocate (except memento allocations)
> and replace with non-folded allocations. The change is based on the
> fact that 1. Those InnerAllocates are not guarded by --allocation-folding
> flag. 2. Hopefully the MemoryOptimizer can handle the folding and no
> performance regression will happen.
>
> Two special versions of InnerAllocate is still kept:
> * One for memento allocations (renamed to InnerAllocateMemento).
> * One for AllocateUninitializedJSArrayWithElements (renamed to InnerAllocateElements).
>
> Change-Id: Ie77da6b2fba31b048241f7b7d927065305a01c27
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873767
> Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74899}
Change-Id: If6a1836634670eff3342f6df1d2a5b76afbdc0ac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2932796
Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74903}
This is a reland of ed7e4554db:
- fixing platform names for tickprocessor
- UnixCppEntriesProvider => LinuxCppEntriesProvider
- MacCppEntriesProvider => MacOSCppEntriesProvider
Original change's description:
> [mjsunit][tools][d8] Full roundtrip tickprocessor test
>
> - Add os.d8Path property
> - Add os.name property
> - Change tickprocssor test to use command line arguments for testing
> various configurations
> - Change tickprocessor test to create a temporary v8.log and read it
> back in on linux only
> - Rearrange code in tickprocessor.mjs to allow instantiating the
> CppEntriesProvider directly
> - Drop complete symbol-list for tickprocessor-test-large.log for better
> code searching in V8
>
> Change-Id: Ib56dd0a1ba5377282c84c4de6f17e2fd69ee8123
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929120
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74892}
Change-Id: I5e121ba11f407af50108a2712d27c32867a22eb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929382
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74902}
... as these jobs may have references to the array backing store and
expect them to stay valid.
Bug: chromium:1211215
Change-Id: Ia48519e993306223afab8d11a94d6d8fc150a11d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928502
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74901}
This CL removes all uses of InnerAllocate (except memento allocations)
and replace with non-folded allocations. The change is based on the
fact that 1. Those InnerAllocates are not guarded by --allocation-folding
flag. 2. Hopefully the MemoryOptimizer can handle the folding and no
performance regression will happen.
Two special versions of InnerAllocate is still kept:
* One for memento allocations (renamed to InnerAllocateMemento).
* One for AllocateUninitializedJSArrayWithElements (renamed to InnerAllocateElements).
Change-Id: Ie77da6b2fba31b048241f7b7d927065305a01c27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873767
Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74899}
These tests are too slow and we get enough coverage by running in
other configurations.
Change-Id: Ib07136b01ae1e5c57589ca97114c283258a958f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929385
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74898}
CompactionSpaces are only used during GC, so there is no need to
lock pending_allocation_mutex_ for them. Locking for GC allocations
actually caused multiple regressions.
Bug: chromium:1214765
Change-Id: I6db4ed96deced41dc52f04b2917ec944b4ccc674
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928189
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74896}
This reverts commit ed7e4554db.
Reason for revert: new test fails on Mac: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64/40407/overview
Original change's description:
> [mjsunit][tools][d8] Full roundtrip tickprocessor test
>
> - Add os.d8Path property
> - Add os.name property
> - Change tickprocssor test to use command line arguments for testing
> various configurations
> - Change tickprocessor test to create a temporary v8.log and read it
> back in on linux only
> - Rearrange code in tickprocessor.mjs to allow instantiating the
> CppEntriesProvider directly
> - Drop complete symbol-list for tickprocessor-test-large.log for better
> code searching in V8
>
> Change-Id: Ib56dd0a1ba5377282c84c4de6f17e2fd69ee8123
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929120
> Reviewed-by: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74892}
Change-Id: I7d7506b370f96365552a21fa767b1c5c608ebb1c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929380
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#74894}
- Add os.d8Path property
- Add os.name property
- Change tickprocssor test to use command line arguments for testing
various configurations
- Change tickprocessor test to create a temporary v8.log and read it
back in on linux only
- Rearrange code in tickprocessor.mjs to allow instantiating the
CppEntriesProvider directly
- Drop complete symbol-list for tickprocessor-test-large.log for better
code searching in V8
Change-Id: Ib56dd0a1ba5377282c84c4de6f17e2fd69ee8123
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929120
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74892}
These tests require Simd enabled which causes failures
on machines without the support.
They are already skipped on Mips: https://crrev.com/c/2841887
Change-Id: I4b9a9bb3cb208a0e9aa12dc135393bc515ad766e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2927210
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74891}
GCC build fails trying to use a non constexpr function from a
constexpr function.
../chromium-92.0.4503.0/v8/src/wasm/baseline/liftoff-register.h: In member function 'constexpr v8::internal::DoubleRegister v8::internal::wasm::LiftoffRegister::fp() const':
../chromium-92.0.4503.0/v8/src/wasm/baseline/liftoff-register.h:286:71: error: call to non-'constexpr' function 'static v8::internal::VRegister v8::internal::VRegister::from_code(int)'
286 | return DoubleRegister::from_code(code_ - kAfterMaxLiftoffGpRegCode);
| ^
In file included from ../chromium-92.0.4503.0/v8/src/codegen/register-arch.h:16,
from ../chromium-92.0.4503.0/v8/src/deoptimizer/translation-array.h:8,
from ../chromium-92.0.4503.0/v8/src/objects/code.h:10,
from ../chromium-92.0.4503.0/v8/src/codegen/reloc-info.h:10,
from ../chromium-92.0.4503.0/v8/src/codegen/assembler.h:47,
from ../chromium-92.0.4503.0/v8/src/codegen/assembler-arch.h:8,
from ../chromium-92.0.4503.0/v8/src/codegen/turbo-assembler.h:12,
from ../chromium-92.0.4503.0/v8/src/codegen/macro-assembler.h:8,
from ../chromium-92.0.4503.0/v8/src/wasm/baseline/liftoff-assembler.h:13,
from ../chromium-92.0.4503.0/v8/src/wasm/baseline/liftoff-assembler.cc:5:
../chromium-92.0.4503.0/v8/src/codegen/arm64/register-arm64.h:416:20: note: 'static v8::internal::VRegister v8::internal::VRegister::from_code(int)' declared here
416 | static VRegister from_code(int code) {
| ^~~~~~~~~
Bug: chromium:819294
Change-Id: Ia19ea90f3f666702d32c90e147af17dcda7e08a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929805
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Cr-Commit-Position: refs/heads/master@{#74889}
Port 2b77ca200c
Original Commit Message:
The upper 32 bits of the 64 bit offset register are not guaranteed to be
cleared, so a zero-extension is needed. We already do the zero-extension
in the case of explicit bounds checking, but this should also be done if
the trap handler is enabled.
R=thibaudm@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ife3ae4f93b85fe1b2c76fe4b98fa408b5b51ed71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2929661
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74886}
The split between "Complete" methods and "Validate" methods is subtle
and undocumented. The "Complete" methods are only used in places where
we know that the function is valid anyway: Printing wasm code and
getting stack effects of an instruction (for the interpreter). Both are
also not performance critical.
Hence this CL merges the "Complete" methods in the respective "Validate"
methods and just call the latter instead of the former.
R=jkummerow@chromium.org
Bug: v8:11831
Change-Id: Id9591c73587262c30b8c56770b090f2b0d2d45b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922118
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74882}
The upper 32 bits of the 64 bit offset register are not guaranteed to be
cleared, so a zero-extension is needed. We already do the zero-extension
in the case of explicit bounds checking, but this should also be done if
the trap handler is enabled.
R=clemensb@chromium.orgCC=jkummerow@chromium.org
Bug: v8:11809
Change-Id: I21e2535c701041d11fa06c176fa683d82db0a3f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917612
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74881}
This CL fixes the deserialization of the map for empty objects, so that
the initial empty map is used.
Bug: chromium:1213851, v8:11525, v8:11706
Change-Id: I37de0b147b9c89ead9c96f776e5fbf88da4630cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928192
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74880}
This CL adds a v8_allocation_site_tracking flag to control the allocation and
tracking of memento objects.
Disables FLAG_allocation_site_pretenuring if v8_allocation_site_tracking
is disabled.
v8_enable_single_generation implies !v8_allocation_site by default.
Change-Id: Ib07528bd37d91de6bb6ea0bfea1699be4e17fae9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897326
Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74879}
NotifyIncrementalMarkingStart() was using a different timer in the
default configuration to set incremental_marking_start_time_.
Bug: v8:11801
Change-Id: I1551bcc659d025bf8c46c865f5d2bd429934f628
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930158
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74878}
In the Chrome DevTools Protocol, the step actions are named StepOut,
StepOver, and StepInto, but internally we used StepOut, StepNext, and
StepIn instead. This change adjusts the naming to be consistent.
Bug: chromium:901814, chromium:1162229
Change-Id: Id3502a1b0a4aadd94734ec3d1fef73c1782fa220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928510
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74877}
Various behaviour preserving changes that make it easier to switch on
callee-saved registers without having to land refactoring code at the
same time.
- Use MaybeStoreRegisters / MaybeRestoreRegisters
- Use CallRecordWriteStubSaveRegisters everywhere for now. Eventually
this will be replaced by CallRecordWriteStub in places with fixed
registers.
- Use WriteBarrierDescriptor::ComputeSavedRegisters, which for now
returns the same as allocatable_registers
Full x64 implementation: https://crrev.com/c/2922604
Bug: v8:11420
Change-Id: I04e6ac2f6333edc91cb1030a0217f59ad441a1d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922250
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74876}
Limit tests to release, linux and macos since they are mostly for
checking whether the tools work correctly rather than JS correctness.
Change-Id: I26e49fbda33a4dac8d774b2e03fa07ae1f2f142a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930156
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74875}
This CL would finish adding TSAN support for the generated tagged
stores.
Bug: v8:7790, v8:11600
Change-Id: Icaadc06ea740089dadf3d9f86da56d84dad1d4b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922113
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74872}
So far, units compiled with TurboFan were published one-by-one as soon
as they were ready, which reduces the latency until the faster code is
available. However, especially when write-protecting code with mprotect,
this yielded a lot of page protection switches, which incurs syscall and
lock contention overhead. Thus, https://crrev.com/c/2922114 already
introduced TurboFan batching when using write-protection.
During experiments, we found this could even be beneficial in the
default configuration, i.e., without write-protection enabled. This CL
changes to always do the publishing in batches. This choice should be
revisited once the tier-up strategy changes, e.g., with lazy compilation
or dynamic tier-up.
R=clemensb@chromium.org
CC=jkummerow@chromium.org
Change-Id: I0ba792c969f7e017ac57103d2bbfe9a142cf302d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928186
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#74871}
This is a reland of 17915002fc with an
added fix for TurboAssembler::CallTSANRelaxedStoreStub.
Original change's description:
> [builtins][x64] Use callee-saved registers for write barrier stubs
>
> Calls to the record write stub are quite frequent and the caller has to
> save all registers used by the builtin.
>
> This CL moves the register saving to the builtin itself, reducing the
> call-site code size significantly in many cases and thus improving
> compilation speed of sparkplug.
>
> Follow-up CLs with introduce the same behaviour to other platforms.
>
> - CallRecordWriteStubSaveRegisters preserves the existing behaviour and
> saves clobbered registers.
> - CallRecordWriteStub expects the registers to match the ones specified
> in the WriteBarrierDescriptor for more compact code.
>
> Bug: v8:11420
> Change-Id: Ib1260cf972712bb9ba879beacd34b06a7fa347f1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922103
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74831}
Bug: v8:11420
Change-Id: Ibac3e6f0360d35579ee0b0dc5d698f8cdab93260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922604
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74870}
All our Simd load/store opcodes are using MRR format.
Added DCHECKs will make sure the passed MemOperands are using
2 registers and not an Immediate value.
Change-Id: Ife470d3c80a10853bbb8365f8c00350ebdc98b2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2927208
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74868}
This will be thrown during array allocations if the requested size is
larger than kV8MaxWasmArrayLength.
Additional changes:
- In test-gc.cc, add the possibility to check against the trap message
in CheckHasThrown.
- Small reorganization of WasmGCTester in test-gc.cc.
Bug: v8:7748
Change-Id: I6f74b525bd7087fcc66f43c451ef130df022b0f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922247
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74867}
AllocationSites are strongly rooted in various places.
AllocationMementos, small heap objects immediately behind the
objects which AllocationSites tracks, are purposely left
unrooted. They do however, point to AllocationSites.
This leads to a situation where an AllocationSite may no longer
be seen to have strong roots at gc time, and yet new space is
still repleat with AllocationMementos which point to it.
The GC recognizes this, and marks the AllocationSite as a
"zombie," that is, an object which should be kept alive for
one more GC cycle because of the existence of those mementos
which point to it.
Change-Id: Ifa720c28f216dee2eaf7edd6f489b5c7427d4353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928500
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74866}
Bug: chromium:1212583
Change-Id: I6cce7e419b108a0d30cf4d9d9bb0ba304fb0803e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922249
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74864}
