This test allocates a large mapping and splits into kThunkBufferSize
areas that it needs to be able to change permissions on. So
kThunkBufferSize needs to be set to the largest page size possible,
which is 64k at the moment.
It doesn't matter if kThunkBufferSize is larger than the actual page
size.
Bug: v8:10808
Change-Id: I3a8947f04a7ec25be49a54015cd128e901065ea6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463404
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#70449}
Apple's upcoming arm64 devices will prevent rwx access to memory,
but in turn provide a new per-thread way to switch between write
and execute permissions. This patch puts that system to use for
the WebAssembly subsystem.
The approach relies on CodeSpaceWriteScope objects for now. That
isn't optimal for background threads (which could stay in "write"
mode permanently instead of toggling), but its simplicity makes
it a good first step.
Background:
https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon
Bug: chromium:1117591
Change-Id: I3b60f0efd34c0fed924dfc71ee2c7805801c5d42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378307
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69791}
This is a reland of c2ea20473d
Original change's description:
> [wasm] Move kMaxWasmCodeSpaceSize to wasm directory
>
> This limit is wasm-internal, and does not need to be exposed via
> src/common/globals.h.
> This CL moves it into the {WasmCodeAllocator}.
>
> Drive-by: Minor simplification in jump table stress test.
>
> R=ecmziegler@chromium.org
>
> Change-Id: Iff8c4657697ae98123d840a022c5b21c4948fcdf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375189
> Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69558}
Change-Id: I6e0432d14d23978dea599233e620e84d8255caf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375388
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69560}
This reverts commit c2ea20473d.
Reason for revert: Link failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20cfi/26209
Original change's description:
> [wasm] Move kMaxWasmCodeSpaceSize to wasm directory
>
> This limit is wasm-internal, and does not need to be exposed via
> src/common/globals.h.
> This CL moves it into the {WasmCodeAllocator}.
>
> Drive-by: Minor simplification in jump table stress test.
>
> R=ecmziegler@chromium.org
>
> Change-Id: Iff8c4657697ae98123d840a022c5b21c4948fcdf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375189
> Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69558}
TBR=clemensb@chromium.org,ecmziegler@chromium.org
Change-Id: Ic3466eb17f2b3dfa4a0864002b0590fa0f571bb5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375387
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69559}
This limit is wasm-internal, and does not need to be exposed via
src/common/globals.h.
This CL moves it into the {WasmCodeAllocator}.
Drive-by: Minor simplification in jump table stress test.
R=ecmziegler@chromium.org
Change-Id: Iff8c4657697ae98123d840a022c5b21c4948fcdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375189
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69558}
Using x16/x17 for tail calls allows us to use a "BTI c" instead
of "BTI jc" landing pad. This means that we cannot enter functions
with a jump to a register other than x16/x17 anymore.
Bug: v8:10026
Change-Id: If5af1af861acc19f9e0dfc19c38d6a57a6fb6b6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2276049
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#68655}
In Liftoff, we have a good estimate about how big the generated code
might get. Also, we often compile hundreds of functions which each hold
an assembler buffer alive until we finally add that code to the wasm
module.
In order to reduce memory consumption in Liftoff, this CL reduces
{AssemblerBase::kMinimalBufferSize} from 4096 to 128, and adds
{AssemblerBase::kDefaultBufferSize} to be used instead.
R=jkummerow@chromium.org
Change-Id: I7029bf501244770f4824a86b233d7f99c4b7910b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914559
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64958}
With the far jump table, we need to distinguish the maximum size of a
single code space from the maximum total code size per module. On
arm64, they differ, because we now support 1GB of code space, but each
code space is still limited to 128MB.
Bug: v8:9477
R=mstarzinger@chromium.org
Change-Id: I7b9aaec56a1d9d1f70573b6b895216d5b3f38346
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1815253
Commit-Queue: Clemens Backes [né Hammacher] <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63961}
If the jump is too large for a near jump, we patch the far jump table
instead, and patch the (near) jump table to jump to the far jump table
slot.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ic9a929b405492c1cfe744738e0807ad4357c53ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1799543
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63754}
The {JumpTableAssembler} should not include {wasm-code-manager.h}. It
only depends on assembler headers in {src/codegen}.
This removes the {flush_i_cache} parameter which is always set anyway,
removes the last include from {src/wasm} and updates the DEPS file to
forbid such includes for the future.
R=mstarzinger@chromium.org
Bug: v8:9396, v8:9477
Change-Id: Id57b35c93155c3eac7c4c9b6a41d3a1c98c0dddc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1801846
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63749}
This is a reland of 1152445367
Original change's description:
> [wasm] Test concurrent code emission
>
> This extends the jump table stress test. Currently, we generate
> different thunks (on the main thread) and then concurrently update the
> jump table to jump to one of these thunks.
> With this CL, we also generate the thunks concurrently. So this also
> tests whether there is proper synchronization between code generation
> and executing it in another thread.
>
> R=ahaas@chromium.org, mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: I3598329e37482ebd27a13acc752581c714226184
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735319
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63097}
Bug: v8:9477
Change-Id: Iac696f1ff3cd5209231a8dd8d1500cf77c2777b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739370
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63138}
This reverts commit 1152445367.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/27728
Original change's description:
> [wasm] Test concurrent code emission
>
> This extends the jump table stress test. Currently, we generate
> different thunks (on the main thread) and then concurrently update the
> jump table to jump to one of these thunks.
> With this CL, we also generate the thunks concurrently. So this also
> tests whether there is proper synchronization between code generation
> and executing it in another thread.
>
> R=ahaas@chromium.org, mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: I3598329e37482ebd27a13acc752581c714226184
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735319
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63097}
TBR=mstarzinger@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I1c95cb43aa23340913de9cfad9988d0c583cc266
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9477
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739368
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63100}
This extends the jump table stress test. Currently, we generate
different thunks (on the main thread) and then concurrently update the
jump table to jump to one of these thunks.
With this CL, we also generate the thunks concurrently. So this also
tests whether there is proper synchronization between code generation
and executing it in another thread.
R=ahaas@chromium.org, mstarzinger@chromium.org
Bug: v8:9477
Change-Id: I3598329e37482ebd27a13acc752581c714226184
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735319
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63097}
This is a reland of a0728e869b
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
Bug: v8:9524
Change-Id: I7d903fb12ddb00909a9429455f46c55db2fd02de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722562
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62974}
We had both jump slots and lazy compile slots in the same table. This
increases the space per slot to the maximum of the two, even though we
often do not use lazy compilation and could have smaller jump slots.
This CL splits the two into two separate tables. The lazy compile table
will only be created on demand, and will never be patched.
The jump table now only contains jumps, and is more compact (which
might improve performance because of improved locality).
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ie182873a1ec612f71d1b54447021a9a8f8ca59db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698393
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62707}
On x64, we allocate one big code region such that we can use near jumps
and near calls. The jump table did not make use of that design yet.
This CL changes that by emitting jump table slots as near jumps. This
also speeds up patching jump table slots significantly, since far jumps
populate the inline constant pool, which is unneeded overhead in this
case.
As a drive-by, this CL cleans up the API of near_call and near_jmp. The
current semantics is broken, and only works because this is only used
for WebAssembly calls which are patched anyway after code generation.
Also, x64 now uses the same path in test-jump-table-assembler.cc as
arm64 to ensure that all targets are within near-call-distance.
R=mstarzinger@chromium.org
Bug: v8:8916
Change-Id: Iffc34e248b72167307ffdab62dd2212c4ae86a32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561313
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60777}
This extends the "test-jump-table-assembler" stress test to supported
architectures. Note that on both PPC and S390 the tests flushes out the
race during jump table patching pretty reliably. Fixing this issue is
outside the scope of this change, this just ensures test coverage exists
but keeps the test in question disabled.
R=clemensh@chromium.org
TEST=cctest/test-jump-table-assembler
BUG=v8:8018
Change-Id: Ia299ed2a42f9858019627270a25026b53f3628d3
Reviewed-on: https://chromium-review.googlesource.com/c/1478200
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59738}
Refactor the AllocateAssemblerBuffer helper for the new Assembler API.
This is the only non-mechanical part, all other callsites that create
Assembler instances can be trivially changed to the new API. This will
be done in a separate CL.
R=mstarzinger@chromium.org
Bug: v8:8689, v8:8562
Change-Id: I6c150748eeea778d9b70f41fd66fbb1221035a1b
Reviewed-on: https://chromium-review.googlesource.com/c/1415490
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58881}
The test was flaky because it assumed that AllocatedAssemblerBuffer
would eventually return an address within near-call range. Rarely, this
did not happen (within the retry limit), and so the test would crash.
This fix allocates a single, kMaxWasmCodeMemory-sized buffer for the
test, and generates call sequences within that buffer.
BUG=v8:8245
Change-Id: I4b44d897c6cbda15a18ab992fa57805de3b2db29
Reviewed-on: https://chromium-review.googlesource.com/c/1347484
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jacob Bramley <jacob.bramley@arm.com>
Cr-Commit-Position: refs/heads/master@{#57898}
This is the port of concurrent jump table patching support to ARM. It
extends the corresponding stress test and changes the encoding of code
targets in jump table slots to use constant pool entries.
R=clemensh@chromium.org
TEST=cctest/test-jump-table-assembler
BUG=v8:8018
Change-Id: I4b709a7f14dace0f4eb9219f995d42ca607bb25f
Reviewed-on: https://chromium-review.googlesource.com/1164952
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54971}
This adds initial support for concurrently patching jump table slots. It
is needed once different Isolates share code (for the --wasm-shared-code
feature). We need to ensure that instructions holding the target address
within a jump table slot do not cross cache-line boundaries. To do this,
the jump table has been split into consecutive pages.
Note that this also adds a stress test for multiple threads hammering at
a single slot concurrently. The test is currently limited to the ia32
and the x64 architecture, but will be extended to cover others. The test
reliably triggers tearing of the target address on almost every run of
the test and hence serves to prevent regressions.
R=clemensh@chromium.org
TEST=cctest/test-jump-table-assembler
BUG=v8:8018
Change-Id: Ife56bbb61ffcae5d8906ca7b8c604b195603707c
Reviewed-on: https://chromium-review.googlesource.com/1163664
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54942}
