v8/src/wasm/wasm-code-manager.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

900 lines
35 KiB
C
Raw Normal View History

Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
// Copyright 2017 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#ifndef V8_WASM_WASM_CODE_MANAGER_H_
#define V8_WASM_WASM_CODE_MANAGER_H_
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
#include <atomic>
2017-11-20 21:34:04 +00:00
#include <map>
#include <memory>
#include <set>
#include <unordered_set>
#include <utility>
#include <vector>
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
#include "src/base/address-region.h"
#include "src/base/bit-field.h"
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
#include "src/base/macros.h"
#include "src/base/optional.h"
#include "src/builtins/builtins-definitions.h"
#include "src/handles/handles.h"
2017-11-20 21:34:04 +00:00
#include "src/trap-handler/trap-handler.h"
#include "src/utils/vector.h"
#include "src/wasm/compilation-environment.h"
#include "src/wasm/wasm-features.h"
#include "src/wasm/wasm-limits.h"
#include "src/wasm/wasm-module-sourcemap.h"
#include "src/wasm/wasm-tier.h"
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
namespace v8 {
namespace internal {
2017-11-20 21:34:04 +00:00
class Code;
class CodeDesc;
class Isolate;
2017-11-20 21:34:04 +00:00
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
namespace wasm {
class DebugInfo;
2017-11-20 21:34:04 +00:00
class NativeModule;
class WasmCodeManager;
struct WasmCompilationResult;
class WasmEngine;
class WasmImportWrapperCache;
2017-11-20 21:34:04 +00:00
struct WasmModule;
// Convenience macro listing all wasm runtime stubs. Note that the first few
// elements of the list coincide with {compiler::TrapId}, order matters.
#define WASM_RUNTIME_STUB_LIST(V, VTRAP) \
FOREACH_WASM_TRAPREASON(VTRAP) \
V(WasmCompileLazy) \
V(WasmDebugBreak) \
V(WasmInt32ToHeapNumber) \
V(WasmTaggedNonSmiToInt32) \
V(WasmFloat32ToNumber) \
V(WasmFloat64ToNumber) \
V(WasmTaggedToFloat64) \
V(WasmAllocateJSArray) \
V(WasmAtomicNotify) \
Reland "[wasm] Refactor AtomicWait implementation" Stack parameters in the StubCallDescriptor were set to the wrong type. I changed it now so that for stack parameters that are specified in the CallInterfaceDescriptor, type specified type is used. All other parameters are assumed to be tagged, as it has been until now. Original change's description: > [wasm] Refactor AtomicWait implementation > > The existing implementation included aspects that are not > straight-forward to implement in Liftoff and seemed inefficient: > * Convert the timeout in WebAssembly code from I64 to F64, just to > convert it back in the runtime. > * On 32-bit platforms this conversion needs an additional C-call. > * Split the I64 expected value from I64 into two I32 values in the > wasm-compiler. > * Ideally the int64-lowering takes care of 32-bit specific handling. > > With this CL the timeout and the expected value are passed as I64 to > the runtime (a builtin moves the I64 into a bigint for that). The > int64-lowering takes care of 32-bit platforms. There are special > builtins for 32-bit platforms, but they are written such that ideally > also the int64-lowering could create them. Bug: v8:10108 Change-Id: Ib87b543666708457c0d686208a86e46cdca3f9a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080362 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#66533}
2020-02-28 13:59:12 +00:00
V(WasmI32AtomicWait32) \
V(WasmI32AtomicWait64) \
V(WasmI64AtomicWait32) \
V(WasmI64AtomicWait64) \
V(WasmRefFunc) \
V(WasmMemoryGrow) \
V(WasmTableInit) \
V(WasmTableCopy) \
V(WasmTableGet) \
V(WasmTableSet) \
V(WasmStackGuard) \
V(WasmStackOverflow) \
V(WasmThrow) \
V(WasmRethrow) \
V(WasmTraceMemory) \
V(AllocateHeapNumber) \
V(ArgumentsAdaptorTrampoline) \
V(BigIntToI32Pair) \
V(BigIntToI64) \
V(DoubleToI) \
V(I32PairToBigInt) \
V(I64ToBigInt) \
V(RecordWrite) \
V(ToNumber)
// Sorted, disjoint and non-overlapping memory regions. A region is of the
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
// form [start, end). So there's no [start, end), [end, other_end),
// because that should have been reduced to [start, other_end).
class V8_EXPORT_PRIVATE DisjointAllocationPool final {
public:
MOVE_ONLY_WITH_DEFAULT_CONSTRUCTORS(DisjointAllocationPool);
explicit DisjointAllocationPool(base::AddressRegion region)
: regions_({region}) {}
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
// Merge the parameter region into this object. The assumption is that the
// passed parameter is not intersecting this object - for example, it was
// obtained from a previous Allocate. Returns the merged region.
base::AddressRegion Merge(base::AddressRegion);
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
// Allocate a contiguous region of size {size}. Return an empty pool on
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
// failure.
base::AddressRegion Allocate(size_t size);
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
// Allocate a contiguous region of size {size} within {region}. Return an
// empty pool on failure.
base::AddressRegion AllocateInRegion(size_t size, base::AddressRegion);
bool IsEmpty() const { return regions_.empty(); }
const auto& regions() const { return regions_; }
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
private:
std::set<base::AddressRegion, base::AddressRegion::StartAddressLess> regions_;
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
};
2017-11-20 21:34:04 +00:00
class V8_EXPORT_PRIVATE WasmCode final {
public:
enum Kind {
kFunction,
kWasmToCapiWrapper,
kWasmToJsWrapper,
2018-06-19 09:47:17 +00:00
kJumpTable
2017-11-20 21:34:04 +00:00
};
// Each runtime stub is identified by an id. This id is used to reference the
// stub via {RelocInfo::WASM_STUB_CALL} and gets resolved during relocation.
enum RuntimeStubId {
#define DEF_ENUM(Name) k##Name,
#define DEF_ENUM_TRAP(Name) kThrowWasm##Name,
WASM_RUNTIME_STUB_LIST(DEF_ENUM, DEF_ENUM_TRAP)
#undef DEF_ENUM_TRAP
#undef DEF_ENUM
kRuntimeStubCount
};
Vector<byte> instructions() const {
return VectorOf(instructions_, static_cast<size_t>(instructions_size_));
}
Address instruction_start() const {
return reinterpret_cast<Address>(instructions_);
}
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
Vector<const byte> reloc_info() const {
return {protected_instructions_data().end(),
static_cast<size_t>(reloc_info_size_)};
}
Vector<const byte> source_positions() const {
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
return {reloc_info().end(), static_cast<size_t>(source_positions_size_)};
}
2017-11-20 21:34:04 +00:00
// TODO(clemensb): Make this return int.
uint32_t index() const {
DCHECK_LE(0, index_);
return index_;
}
// Anonymous functions are functions that don't carry an index.
bool IsAnonymous() const { return index_ == kAnonymousFuncIndex; }
Kind kind() const { return KindField::decode(flags_); }
NativeModule* native_module() const { return native_module_; }
ExecutionTier tier() const { return ExecutionTierField::decode(flags_); }
2017-11-20 21:34:04 +00:00
Address constant_pool() const;
Address handler_table() const;
int handler_table_size() const;
Reland "Reland "Reland "[code-comments] Put code comments into the code object""" This is a reland of 9c0a48580bc820d93a16f8914281a7359beb2a7a Original change's description: > Reland "Reland "[code-comments] Put code comments into the code object"" > > This is a reland of ed3d647284538e9d6f013ebf2c460697aa06a5df > > This reland fixes that padding at the end of Wasm instruction streams > triggered asserts in the code printer. > > Original change's description: > > Reland "[code-comments] Put code comments into the code object" > > > > This is a reland of e774cffe2bd3f00332209d4d5695221963888c96 > > > > This reland disables a test as v8:8548 is blocking it, which was > > broken by a recent CL. CQ did not catch this because the merge-base > > CQ used did not yet contain the CL that caused v8:8548. > > > > Original change's description: > > > [code-comments] Put code comments into the code object > > > > > > Code comments in the snapshot can now be enabled with gn > > > arg 'v8_enable_snapshot_code_comments' > > > > > > Bug: v8:7989 > > > Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3 > > > Reviewed-on: https://chromium-review.googlesource.com/c/1329173 > > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#58020} > > > > TBR=mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tebbi@chromium.org > > > > Bug: v8:7989, v8:8548 > > Change-Id: I464fc897205fefdf2dfc2eadc54d699c4e08a0e9 > > Reviewed-on: https://chromium-review.googlesource.com/c/1361166 > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58028} > > Bug: v8:7989, v8:8548 > Change-Id: I254f55ff687ad049f8d92b09331ed26a2bd05d7d > Reviewed-on: https://chromium-review.googlesource.com/c/1371784 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58221} TBR=jgruber@chromium.org,mstarzinger@chromium.org Bug: v8:7989, v8:8548, v8:8593 Change-Id: I4f7ffc98e0281c7b744eb4a04ba0763896c7b59b Reviewed-on: https://chromium-review.googlesource.com/c/1375919 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58232}
2018-12-13 19:30:56 +00:00
Address code_comments() const;
int code_comments_size() const;
int constant_pool_offset() const { return constant_pool_offset_; }
int safepoint_table_offset() const { return safepoint_table_offset_; }
int handler_table_offset() const { return handler_table_offset_; }
int code_comments_offset() const { return code_comments_offset_; }
int unpadded_binary_size() const { return unpadded_binary_size_; }
int stack_slots() const { return stack_slots_; }
int tagged_parameter_slots() const { return tagged_parameter_slots_; }
bool is_liftoff() const { return tier() == ExecutionTier::kLiftoff; }
bool contains(Address pc) const {
return reinterpret_cast<Address>(instructions_) <= pc &&
pc < reinterpret_cast<Address>(instructions_ + instructions_size_);
}
2017-11-20 21:34:04 +00:00
// Only Liftoff code that was generated for debugging can be inspected
// (otherwise debug side table positions would not match up).
bool is_inspectable() const { return is_liftoff() && for_debugging(); }
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
Vector<const uint8_t> protected_instructions_data() const {
return {meta_data_.get(),
static_cast<size_t>(protected_instructions_size_)};
}
Vector<const trap_handler::ProtectedInstructionData> protected_instructions()
const {
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
return Vector<const trap_handler::ProtectedInstructionData>::cast(
protected_instructions_data());
2017-11-20 21:34:04 +00:00
}
void Validate() const;
void Print(const char* name = nullptr) const;
void MaybePrint(const char* name = nullptr) const;
void Disassemble(const char* name, std::ostream& os,
Address current_pc = kNullAddress) const;
2017-11-20 21:34:04 +00:00
static bool ShouldBeLogged(Isolate* isolate);
void LogCode(Isolate* isolate) const;
2017-11-20 21:34:04 +00:00
~WasmCode();
void IncRef() {
int old_val = ref_count_.fetch_add(1, std::memory_order_acq_rel);
DCHECK_LE(1, old_val);
DCHECK_GT(kMaxInt, old_val);
USE(old_val);
}
// Decrement the ref count. Returns whether this code becomes dead and needs
// to be freed.
V8_WARN_UNUSED_RESULT bool DecRef() {
int old_count = ref_count_.load(std::memory_order_acquire);
while (true) {
DCHECK_LE(1, old_count);
if (V8_UNLIKELY(old_count == 1)) return DecRefOnPotentiallyDeadCode();
if (ref_count_.compare_exchange_weak(old_count, old_count - 1,
std::memory_order_acq_rel)) {
return false;
}
}
}
// Decrement the ref count on code that is known to be dead, even though there
// might still be C++ references. Returns whether this drops the last
// reference and the code needs to be freed.
V8_WARN_UNUSED_RESULT bool DecRefOnDeadCode() {
return ref_count_.fetch_sub(1, std::memory_order_acq_rel) == 1;
}
// Decrement the ref count on a set of {WasmCode} objects, potentially
// belonging to different {NativeModule}s. Dead code will be deleted.
static void DecrementRefCount(Vector<WasmCode* const>);
// Returns the last source position before {offset}.
int GetSourcePositionBefore(int offset);
// Returns whether this code was generated for debugging. If this returns
// {kForDebugging}, but {tier()} is not {kLiftoff}, then Liftoff compilation
// bailed out.
ForDebugging for_debugging() const {
return ForDebuggingField::decode(flags_);
}
enum FlushICache : bool { kFlushICache = true, kNoFlushICache = false };
2017-11-20 21:34:04 +00:00
private:
friend class NativeModule;
WasmCode(NativeModule* native_module, int index, Vector<byte> instructions,
int stack_slots, int tagged_parameter_slots,
int safepoint_table_offset, int handler_table_offset,
int constant_pool_offset, int code_comments_offset,
int unpadded_binary_size,
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
Vector<const byte> protected_instructions_data,
Vector<const byte> reloc_info,
Vector<const byte> source_position_table, Kind kind,
ExecutionTier tier, ForDebugging for_debugging)
: native_module_(native_module),
instructions_(instructions.begin()),
flags_(KindField::encode(kind) | ExecutionTierField::encode(tier) |
ForDebuggingField::encode(for_debugging)),
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
meta_data_(ConcatenateBytes(
{protected_instructions_data, reloc_info, source_position_table})),
instructions_size_(instructions.length()),
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
reloc_info_size_(reloc_info.length()),
source_positions_size_(source_position_table.length()),
protected_instructions_size_(protected_instructions_data.length()),
2017-11-20 21:34:04 +00:00
index_(index),
constant_pool_offset_(constant_pool_offset),
stack_slots_(stack_slots),
tagged_parameter_slots_(tagged_parameter_slots),
2017-11-20 21:34:04 +00:00
safepoint_table_offset_(safepoint_table_offset),
handler_table_offset_(handler_table_offset),
Reland "Reland "Reland "[code-comments] Put code comments into the code object""" This is a reland of 9c0a48580bc820d93a16f8914281a7359beb2a7a Original change's description: > Reland "Reland "[code-comments] Put code comments into the code object"" > > This is a reland of ed3d647284538e9d6f013ebf2c460697aa06a5df > > This reland fixes that padding at the end of Wasm instruction streams > triggered asserts in the code printer. > > Original change's description: > > Reland "[code-comments] Put code comments into the code object" > > > > This is a reland of e774cffe2bd3f00332209d4d5695221963888c96 > > > > This reland disables a test as v8:8548 is blocking it, which was > > broken by a recent CL. CQ did not catch this because the merge-base > > CQ used did not yet contain the CL that caused v8:8548. > > > > Original change's description: > > > [code-comments] Put code comments into the code object > > > > > > Code comments in the snapshot can now be enabled with gn > > > arg 'v8_enable_snapshot_code_comments' > > > > > > Bug: v8:7989 > > > Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3 > > > Reviewed-on: https://chromium-review.googlesource.com/c/1329173 > > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#58020} > > > > TBR=mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tebbi@chromium.org > > > > Bug: v8:7989, v8:8548 > > Change-Id: I464fc897205fefdf2dfc2eadc54d699c4e08a0e9 > > Reviewed-on: https://chromium-review.googlesource.com/c/1361166 > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58028} > > Bug: v8:7989, v8:8548 > Change-Id: I254f55ff687ad049f8d92b09331ed26a2bd05d7d > Reviewed-on: https://chromium-review.googlesource.com/c/1371784 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58221} TBR=jgruber@chromium.org,mstarzinger@chromium.org Bug: v8:7989, v8:8548, v8:8593 Change-Id: I4f7ffc98e0281c7b744eb4a04ba0763896c7b59b Reviewed-on: https://chromium-review.googlesource.com/c/1375919 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58232}
2018-12-13 19:30:56 +00:00
code_comments_offset_(code_comments_offset),
unpadded_binary_size_(unpadded_binary_size) {
Reland "Reland "Reland "[code-comments] Put code comments into the code object""" This is a reland of 9c0a48580bc820d93a16f8914281a7359beb2a7a Original change's description: > Reland "Reland "[code-comments] Put code comments into the code object"" > > This is a reland of ed3d647284538e9d6f013ebf2c460697aa06a5df > > This reland fixes that padding at the end of Wasm instruction streams > triggered asserts in the code printer. > > Original change's description: > > Reland "[code-comments] Put code comments into the code object" > > > > This is a reland of e774cffe2bd3f00332209d4d5695221963888c96 > > > > This reland disables a test as v8:8548 is blocking it, which was > > broken by a recent CL. CQ did not catch this because the merge-base > > CQ used did not yet contain the CL that caused v8:8548. > > > > Original change's description: > > > [code-comments] Put code comments into the code object > > > > > > Code comments in the snapshot can now be enabled with gn > > > arg 'v8_enable_snapshot_code_comments' > > > > > > Bug: v8:7989 > > > Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3 > > > Reviewed-on: https://chromium-review.googlesource.com/c/1329173 > > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#58020} > > > > TBR=mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tebbi@chromium.org > > > > Bug: v8:7989, v8:8548 > > Change-Id: I464fc897205fefdf2dfc2eadc54d699c4e08a0e9 > > Reviewed-on: https://chromium-review.googlesource.com/c/1361166 > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58028} > > Bug: v8:7989, v8:8548 > Change-Id: I254f55ff687ad049f8d92b09331ed26a2bd05d7d > Reviewed-on: https://chromium-review.googlesource.com/c/1371784 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58221} TBR=jgruber@chromium.org,mstarzinger@chromium.org Bug: v8:7989, v8:8548, v8:8593 Change-Id: I4f7ffc98e0281c7b744eb4a04ba0763896c7b59b Reviewed-on: https://chromium-review.googlesource.com/c/1375919 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58232}
2018-12-13 19:30:56 +00:00
DCHECK_LE(safepoint_table_offset, unpadded_binary_size);
DCHECK_LE(handler_table_offset, unpadded_binary_size);
DCHECK_LE(code_comments_offset, unpadded_binary_size);
DCHECK_LE(constant_pool_offset, unpadded_binary_size);
}
2017-11-20 21:34:04 +00:00
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
std::unique_ptr<const byte[]> ConcatenateBytes(
std::initializer_list<Vector<const byte>>);
// Code objects that have been registered with the global trap handler within
// this process, will have a {trap_handler_index} associated with them.
int trap_handler_index() const {
CHECK(has_trap_handler_index());
return trap_handler_index_;
}
void set_trap_handler_index(int value) {
CHECK(!has_trap_handler_index());
trap_handler_index_ = value;
}
bool has_trap_handler_index() const { return trap_handler_index_ >= 0; }
// Register protected instruction information with the trap handler. Sets
// trap_handler_index.
void RegisterTrapHandlerData();
// Slow path for {DecRef}: The code becomes potentially dead.
// Returns whether this code becomes dead and needs to be freed.
V8_NOINLINE bool DecRefOnPotentiallyDeadCode();
NativeModule* const native_module_ = nullptr;
byte* const instructions_;
const uint8_t flags_; // Bit field, see below.
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
// {meta_data_} contains several byte vectors concatenated into one:
// - protected instructions data of size {protected_instructions_size_}
// - relocation info of size {reloc_info_size_}
// - source positions of size {source_positions_size_}
// Note that the protected instructions come first to ensure alignment.
std::unique_ptr<const byte[]> meta_data_;
const int instructions_size_;
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
const int reloc_info_size_;
const int source_positions_size_;
const int protected_instructions_size_;
const int index_;
const int constant_pool_offset_;
const int stack_slots_;
// Number of tagged parameters passed to this function via the stack. This
// value is used by the stack walker (e.g. GC) to find references.
const int tagged_parameter_slots_;
// We care about safepoint data for wasm-to-js functions, since there may be
// stack/register tagged values for large number conversions.
const int safepoint_table_offset_;
const int handler_table_offset_;
const int code_comments_offset_;
const int unpadded_binary_size_;
int trap_handler_index_ = -1;
// Bits encoded in {flags_}:
using KindField = base::BitField8<Kind, 0, 3>;
using ExecutionTierField = KindField::Next<ExecutionTier, 2>;
using ForDebuggingField = ExecutionTierField::Next<ForDebugging, 2>;
// WasmCode is ref counted. Counters are held by:
// 1) The jump table / code table.
// 2) {WasmCodeRefScope}s.
// 3) The set of potentially dead code in the {WasmEngine}.
// If a decrement of (1) would drop the ref count to 0, that code becomes a
// candidate for garbage collection. At that point, we add a ref count for (3)
// *before* decrementing the counter to ensure the code stays alive as long as
// it's being used. Once the ref count drops to zero (i.e. after being removed
// from (3) and all (2)), the code object is deleted and the memory for the
// machine code is freed.
std::atomic<int> ref_count_{1};
DISALLOW_COPY_AND_ASSIGN(WasmCode);
2017-11-20 21:34:04 +00:00
};
// Check that {WasmCode} objects are sufficiently small. We create many of them,
// often for rather small functions.
// Increase the limit if needed, but first check if the size increase is
// justified.
STATIC_ASSERT(sizeof(WasmCode) <= 88);
WasmCode::Kind GetCodeKind(const WasmCompilationResult& result);
// Return a textual description of the kind.
const char* GetWasmCodeKindAsString(WasmCode::Kind);
// Manages the code reservations and allocations of a single {NativeModule}.
class WasmCodeAllocator {
public:
// {OptionalLock} is passed between {WasmCodeAllocator} and {NativeModule} to
// indicate that the lock on the {WasmCodeAllocator} is already taken. It's
// optional to allow to also call methods without holding the lock.
class OptionalLock {
public:
// External users can only instantiate a non-locked {OptionalLock}.
OptionalLock() = default;
~OptionalLock();
bool is_locked() const { return allocator_ != nullptr; }
private:
friend class WasmCodeAllocator;
// {Lock} is called from the {WasmCodeAllocator} if no locked {OptionalLock}
// is passed.
void Lock(WasmCodeAllocator*);
WasmCodeAllocator* allocator_ = nullptr;
};
WasmCodeAllocator(WasmCodeManager*, VirtualMemory code_space,
std::shared_ptr<Counters> async_counters);
~WasmCodeAllocator();
// Call before use, after the {NativeModule} is set up completely.
void Init(NativeModule*);
size_t committed_code_space() const {
return committed_code_space_.load(std::memory_order_acquire);
}
size_t generated_code_size() const {
return generated_code_size_.load(std::memory_order_acquire);
}
size_t freed_code_size() const {
return freed_code_size_.load(std::memory_order_acquire);
}
// Allocate code space. Returns a valid buffer or fails with OOM (crash).
Vector<byte> AllocateForCode(NativeModule*, size_t size);
// Allocate code space within a specific region. Returns a valid buffer or
// fails with OOM (crash).
Vector<byte> AllocateForCodeInRegion(NativeModule*, size_t size,
base::AddressRegion,
const WasmCodeAllocator::OptionalLock&);
// Sets permissions of all owned code space to executable, or read-write (if
// {executable} is false). Returns true on success.
V8_EXPORT_PRIVATE bool SetExecutable(bool executable);
// Free memory pages of all given code objects. Used for wasm code GC.
void FreeCode(Vector<WasmCode* const>);
// Retrieve the number of separately reserved code spaces.
size_t GetNumCodeSpaces() const;
private:
// The engine-wide wasm code manager.
WasmCodeManager* const code_manager_;
mutable base::Mutex mutex_;
//////////////////////////////////////////////////////////////////////////////
// Protected by {mutex_}:
// Code space that was reserved and is available for allocations (subset of
// {owned_code_space_}).
DisjointAllocationPool free_code_space_;
// Code space that was allocated for code (subset of {owned_code_space_}).
DisjointAllocationPool allocated_code_space_;
// Code space that was allocated before but is dead now. Full pages within
// this region are discarded. It's still a subset of {owned_code_space_}.
DisjointAllocationPool freed_code_space_;
std::vector<VirtualMemory> owned_code_space_;
// End of fields protected by {mutex_}.
//////////////////////////////////////////////////////////////////////////////
std::atomic<size_t> committed_code_space_{0};
std::atomic<size_t> generated_code_size_{0};
std::atomic<size_t> freed_code_size_{0};
bool is_executable_ = false;
std::shared_ptr<Counters> async_counters_;
};
2017-11-20 21:34:04 +00:00
class V8_EXPORT_PRIVATE NativeModule final {
public:
#if V8_TARGET_ARCH_X64 || V8_TARGET_ARCH_S390X || V8_TARGET_ARCH_ARM64
static constexpr bool kNeedsFarJumpsBetweenCodeSpaces = true;
#else
static constexpr bool kNeedsFarJumpsBetweenCodeSpaces = false;
#endif
// {AddCode} is thread safe w.r.t. other calls to {AddCode} or methods adding
// code below, i.e. it can be called concurrently from background threads.
[wasm] Split adding code from publishing it This prepares a refactoring to add and publish compilation results in batches. For this, we need to separate the two phases, so that we can lock the module, allocate all the code space, release the lock, copy the code, lock the module, publish the code, and release the lock again. In particular, this CL does the following: 1) It removes the {AddOwnedCode} method. The functionality of creating the {WasmCode} and memcpy'ing the instruction into that is done in the other {Add*Code} methods. Adding to {owned_code_} is done in {PublishCode}. 2) {PublishInterpreterEntry} is now functionally equivalent to {PublishCode}, so it's removed. 3) After {AddCode}, the caller has to call {PublishCode}. In a follow-up CL, this will be called in batches (first {AddCode} them all, then {PublishCode} them all). 4) {AddCompiledCode} now assumes that the {WasmCompilationResult} succeeded. Otherwise, the caller should directly call {SetError} on the {CompilationState}. 5) {PublishCode} is now the chokepoint for installing code to the code table, the owned code vector, the jump table, and setting interpreter redirections. It replaces previous direct calls to {InstallCode} or explicitly adding to {owned_code_}. 6) Increasing the {generated_code_size_} counter is now done in {AllocateForCode}, which is the chokepoint for allocating space for generated code. This way, we will only increase this counter once once we allocate in batches. R=titzer@chromium.org Bug: v8:8916 Change-Id: I71e02e3a838f21797915cee3ebd373804fb12237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530817 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60369}
2019-03-20 13:04:33 +00:00
// The returned code still needs to be published via {PublishCode}.
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
std::unique_ptr<WasmCode> AddCode(int index, const CodeDesc& desc,
int stack_slots, int tagged_parameter_slots,
Vector<const byte> protected_instructions,
Vector<const byte> source_position_table,
WasmCode::Kind kind, ExecutionTier tier,
ForDebugging for_debugging);
[wasm] Split adding code from publishing it This prepares a refactoring to add and publish compilation results in batches. For this, we need to separate the two phases, so that we can lock the module, allocate all the code space, release the lock, copy the code, lock the module, publish the code, and release the lock again. In particular, this CL does the following: 1) It removes the {AddOwnedCode} method. The functionality of creating the {WasmCode} and memcpy'ing the instruction into that is done in the other {Add*Code} methods. Adding to {owned_code_} is done in {PublishCode}. 2) {PublishInterpreterEntry} is now functionally equivalent to {PublishCode}, so it's removed. 3) After {AddCode}, the caller has to call {PublishCode}. In a follow-up CL, this will be called in batches (first {AddCode} them all, then {PublishCode} them all). 4) {AddCompiledCode} now assumes that the {WasmCompilationResult} succeeded. Otherwise, the caller should directly call {SetError} on the {CompilationState}. 5) {PublishCode} is now the chokepoint for installing code to the code table, the owned code vector, the jump table, and setting interpreter redirections. It replaces previous direct calls to {InstallCode} or explicitly adding to {owned_code_}. 6) Increasing the {generated_code_size_} counter is now done in {AllocateForCode}, which is the chokepoint for allocating space for generated code. This way, we will only increase this counter once once we allocate in batches. R=titzer@chromium.org Bug: v8:8916 Change-Id: I71e02e3a838f21797915cee3ebd373804fb12237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530817 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60369}
2019-03-20 13:04:33 +00:00
// {PublishCode} makes the code available to the system by entering it into
// the code table and patching the jump table. It returns a raw pointer to the
// given {WasmCode} object. Ownership is transferred to the {NativeModule}.
WasmCode* PublishCode(std::unique_ptr<WasmCode>);
std::vector<WasmCode*> PublishCode(Vector<std::unique_ptr<WasmCode>>);
2017-11-20 21:34:04 +00:00
WasmCode* AddDeserializedCode(
int index, Vector<const byte> instructions, int stack_slots,
int tagged_parameter_slots, int safepoint_table_offset,
int handler_table_offset, int constant_pool_offset,
int code_comments_offset, int unpadded_binary_size,
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
Vector<const byte> protected_instructions_data,
Vector<const byte> reloc_info, Vector<const byte> source_position_table,
WasmCode::Kind kind, ExecutionTier tier);
// Adds anonymous code for testing purposes.
WasmCode* AddCodeForTesting(Handle<Code> code);
// Use {UseLazyStub} to setup lazy compilation per function. It will use the
// existing {WasmCode::kWasmCompileLazy} runtime stub and populate the jump
// table with trampolines accordingly.
void UseLazyStub(uint32_t func_index);
2017-11-20 21:34:04 +00:00
// Creates a snapshot of the current state of the code table. This is useful
// to get a consistent view of the table (e.g. used by the serializer).
std::vector<WasmCode*> SnapshotCodeTable() const;
WasmCode* GetCode(uint32_t index) const;
bool HasCode(uint32_t index) const;
bool HasCodeWithTier(uint32_t index, ExecutionTier tier) const;
void SetWasmSourceMap(std::unique_ptr<WasmModuleSourceMap> source_map);
WasmModuleSourceMap* GetWasmSourceMap() const;
Address jump_table_start() const {
return main_jump_table_ ? main_jump_table_->instruction_start()
: kNullAddress;
}
uint32_t GetJumpTableOffset(uint32_t func_index) const;
// Returns the canonical target to call for the given function (the slot in
// the first jump table).
2018-06-19 09:47:17 +00:00
Address GetCallTargetForFunction(uint32_t func_index) const;
2017-11-20 21:34:04 +00:00
struct JumpTablesRef {
const Address jump_table_start = kNullAddress;
const Address far_jump_table_start = kNullAddress;
bool is_valid() const { return far_jump_table_start != kNullAddress; }
};
// Finds the jump tables that should be used for given code region. This
// information is then passed to {GetNearCallTargetForFunction} and
// {GetNearRuntimeStubEntry} to avoid the overhead of looking this information
// up there. Return an empty struct if no suitable jump tables exist.
JumpTablesRef FindJumpTablesForRegion(base::AddressRegion) const;
// Similarly to {GetCallTargetForFunction}, but uses the jump table previously
// looked up via {FindJumpTablesForRegion}.
Address GetNearCallTargetForFunction(uint32_t func_index,
const JumpTablesRef&) const;
// Get a runtime stub entry (which is a far jump table slot) in the jump table
// previously looked up via {FindJumpTablesForRegion}.
Address GetNearRuntimeStubEntry(WasmCode::RuntimeStubId index,
const JumpTablesRef&) const;
// Reverse lookup from a given call target (which must be a jump table slot)
// to a function index.
uint32_t GetFunctionIndexFromJumpTableSlot(Address slot_address) const;
bool SetExecutable(bool executable) {
return code_allocator_.SetExecutable(executable);
}
2017-11-20 21:34:04 +00:00
// For cctests, where we build both WasmModule and the runtime objects
// on the fly, and bypass the instance builder pipeline.
void ReserveCodeTableForTesting(uint32_t max_functions);
2017-11-20 21:34:04 +00:00
void LogWasmCodes(Isolate* isolate);
CompilationState* compilation_state() { return compilation_state_.get(); }
Reland "[wasm] Decouple background compile jobs from NativeModule" This is a reland of 92d9b09c0e68382d1427ad25c70db016bb9e5b80. Patch unchanged, errors fixed by https://crrev.com/c/1430059. Original change's description: > [wasm] Decouple background compile jobs from NativeModule > > Background compile jobs should not keep the NativeModule alive, for two > reasons: > 1) We sometimes have to wait for background compilation to finish (from > a foreground task!). This introduces unnecessary latency. > 2) Giving the background compile tasks shared ownership of the > NativeModule causes the NativeModule (and the CompilationState) to > be freed from background tasks, which is error-prone (see > https://crrev.com/c/1400420). > > Instead, this CL introduces a BackgroundCompileToken which is held > alive by the NativeModule and all background compile jobs. The initial > and the final phase of compilation (getting and submitting work) > synchronize on this token to check and ensure that the NativeModule is > and stays alive. During compilation itself, the mutex is released, such > that the NativeModule can die. > The destructor of the NativeModule cancels the BackgroundCompileToken. > Immediately afterwards, the NativeModule and the CompilationState can > die. > > This change allows to remove two hacks introduced previously: The atomic > {aborted_} flag and the {FreeCallbacksTask}. > > R=mstarzinger@chromium.org > CC=titzer@chromium.org > > Bug: v8:8689, v8:7921 > Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6 > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel > Reviewed-on: https://chromium-review.googlesource.com/c/1421364 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59020} TBR=mstarzinger@chromium.org Bug: v8:8689, v8:7921 Change-Id: Iead972ef77c8503da7246cab48e7693b176d8f02 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Reviewed-on: https://chromium-review.googlesource.com/c/1429862 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59035}
2019-01-23 11:49:36 +00:00
// Create a {CompilationEnv} object for compilation. The caller has to ensure
// that the {WasmModule} pointer stays valid while the {CompilationEnv} is
// being used.
CompilationEnv CreateCompilationEnv() const;
uint32_t num_functions() const {
return module_->num_declared_functions + module_->num_imported_functions;
}
uint32_t num_imported_functions() const {
return module_->num_imported_functions;
}
UseTrapHandler use_trap_handler() const { return use_trap_handler_; }
void set_lazy_compile_frozen(bool frozen) { lazy_compile_frozen_ = frozen; }
bool lazy_compile_frozen() const { return lazy_compile_frozen_; }
Vector<const uint8_t> wire_bytes() const { return wire_bytes_->as_vector(); }
const WasmModule* module() const { return module_.get(); }
Reland "[wasm] Decouple background compile jobs from NativeModule" This is a reland of 92d9b09c0e68382d1427ad25c70db016bb9e5b80. Patch unchanged, errors fixed by https://crrev.com/c/1430059. Original change's description: > [wasm] Decouple background compile jobs from NativeModule > > Background compile jobs should not keep the NativeModule alive, for two > reasons: > 1) We sometimes have to wait for background compilation to finish (from > a foreground task!). This introduces unnecessary latency. > 2) Giving the background compile tasks shared ownership of the > NativeModule causes the NativeModule (and the CompilationState) to > be freed from background tasks, which is error-prone (see > https://crrev.com/c/1400420). > > Instead, this CL introduces a BackgroundCompileToken which is held > alive by the NativeModule and all background compile jobs. The initial > and the final phase of compilation (getting and submitting work) > synchronize on this token to check and ensure that the NativeModule is > and stays alive. During compilation itself, the mutex is released, such > that the NativeModule can die. > The destructor of the NativeModule cancels the BackgroundCompileToken. > Immediately afterwards, the NativeModule and the CompilationState can > die. > > This change allows to remove two hacks introduced previously: The atomic > {aborted_} flag and the {FreeCallbacksTask}. > > R=mstarzinger@chromium.org > CC=titzer@chromium.org > > Bug: v8:8689, v8:7921 > Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6 > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel > Reviewed-on: https://chromium-review.googlesource.com/c/1421364 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59020} TBR=mstarzinger@chromium.org Bug: v8:8689, v8:7921 Change-Id: Iead972ef77c8503da7246cab48e7693b176d8f02 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Reviewed-on: https://chromium-review.googlesource.com/c/1429862 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59035}
2019-01-23 11:49:36 +00:00
std::shared_ptr<const WasmModule> shared_module() const { return module_; }
size_t committed_code_space() const {
return code_allocator_.committed_code_space();
}
WasmEngine* engine() const { return engine_; }
void SetWireBytes(OwnedVector<const uint8_t> wire_bytes);
2018-06-19 09:47:17 +00:00
WasmCode* Lookup(Address) const;
WasmImportWrapperCache* import_wrapper_cache() const {
return import_wrapper_cache_.get();
}
2017-11-20 21:34:04 +00:00
~NativeModule();
const WasmFeatures& enabled_features() const { return enabled_features_; }
// Returns the runtime stub id that corresponds to the given address (which
// must be a far jump table slot). Returns {kRuntimeStubCount} on failure.
WasmCode::RuntimeStubId GetRuntimeStubId(Address runtime_stub_target) const;
// Sample the current code size of this modules to the given counters.
enum CodeSamplingTime : int8_t { kAfterBaseline, kAfterTopTier, kSampling };
void SampleCodeSize(Counters*, CodeSamplingTime) const;
V8_WARN_UNUSED_RESULT std::unique_ptr<WasmCode> AddCompiledCode(
WasmCompilationResult);
V8_WARN_UNUSED_RESULT std::vector<std::unique_ptr<WasmCode>> AddCompiledCode(
Vector<WasmCompilationResult>);
Reland "[wasm][debug] Fix tier down for multiple isolates" This is a reland of 902f48bddad82337349ea3bc5029b38d9ffec11a, fixed to avoid lock inversion problems detected by TSan. Original change's description: > [wasm][debug] Fix tier down for multiple isolates > > If multiple isolates are using the same module, we need to keep it > tiered down as long as any isolate still has a debugger open. > Also, we cannot short-cut the {NativeModule::TierDown} method, since the > previously triggered tier down might not have finished yet. > For now, each isolate starts an independent tier down (i.e. a full > recompilation). We could optimize this later by skipping functions that > are already tiered down, or are already scheduled for tier down, but we > still need to wait for tier-down to finish on each isolate. > > R=thibaudm@chromium.org > > Bug: v8:10359 > Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67716} Bug: v8:10359 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Change-Id: Ie98cf073fc79e5c6991df6d4466de7b560274070 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194451 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67754}
2020-05-12 14:50:31 +00:00
// Set a new tiering state, but don't trigger any recompilation yet; use
// {TriggerRecompilation} for that. The two steps are split because In some
// scenarios we need to drop locks before triggering recompilation.
void SetTieringState(TieringState);
Reland "[wasm][debug] Fix tier down for multiple isolates" This is a reland of 902f48bddad82337349ea3bc5029b38d9ffec11a, fixed to avoid lock inversion problems detected by TSan. Original change's description: > [wasm][debug] Fix tier down for multiple isolates > > If multiple isolates are using the same module, we need to keep it > tiered down as long as any isolate still has a debugger open. > Also, we cannot short-cut the {NativeModule::TierDown} method, since the > previously triggered tier down might not have finished yet. > For now, each isolate starts an independent tier down (i.e. a full > recompilation). We could optimize this later by skipping functions that > are already tiered down, or are already scheduled for tier down, but we > still need to wait for tier-down to finish on each isolate. > > R=thibaudm@chromium.org > > Bug: v8:10359 > Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67716} Bug: v8:10359 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Change-Id: Ie98cf073fc79e5c6991df6d4466de7b560274070 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194451 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67754}
2020-05-12 14:50:31 +00:00
// Check whether this modules is tiered down for debugging.
bool IsTieredDown();
Reland "[wasm][debug] Fix tier down for multiple isolates" This is a reland of 902f48bddad82337349ea3bc5029b38d9ffec11a, fixed to avoid lock inversion problems detected by TSan. Original change's description: > [wasm][debug] Fix tier down for multiple isolates > > If multiple isolates are using the same module, we need to keep it > tiered down as long as any isolate still has a debugger open. > Also, we cannot short-cut the {NativeModule::TierDown} method, since the > previously triggered tier down might not have finished yet. > For now, each isolate starts an independent tier down (i.e. a full > recompilation). We could optimize this later by skipping functions that > are already tiered down, or are already scheduled for tier down, but we > still need to wait for tier-down to finish on each isolate. > > R=thibaudm@chromium.org > > Bug: v8:10359 > Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67716} Bug: v8:10359 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Change-Id: Ie98cf073fc79e5c6991df6d4466de7b560274070 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194451 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67754}
2020-05-12 14:50:31 +00:00
// Trigger a full recompilation of this module, in the tier set previously via
// {SetTieringState}. When tiering down, the calling thread contributes to
// compilation and only returns once recompilation is done. Tiering up happens
// concurrently, so this method might return before it is complete.
void TriggerRecompilation();
// Free a set of functions of this module. Uncommits whole pages if possible.
// The given vector must be ordered by the instruction start address, and all
// {WasmCode} objects must not be used any more.
// Should only be called via {WasmEngine::FreeDeadCode}, so the engine can do
// its accounting.
void FreeCode(Vector<WasmCode* const>);
// Retrieve the number of separately reserved code spaces for this module.
size_t GetNumberOfCodeSpacesForTesting() const;
// Check whether there is DebugInfo for this NativeModule.
bool HasDebugInfo() const;
// Get or create the debug info for this NativeModule.
DebugInfo* GetDebugInfo();
2017-11-20 21:34:04 +00:00
private:
friend class WasmCode;
friend class WasmCodeAllocator;
2017-11-20 21:34:04 +00:00
friend class WasmCodeManager;
friend class NativeModuleModificationScope;
2017-11-20 21:34:04 +00:00
struct CodeSpaceData {
base::AddressRegion region;
WasmCode* jump_table;
WasmCode* far_jump_table;
};
// Private constructor, called via {WasmCodeManager::NewNativeModule()}.
NativeModule(WasmEngine* engine, const WasmFeatures& enabled_features,
VirtualMemory code_space,
std::shared_ptr<const WasmModule> module,
std::shared_ptr<Counters> async_counters,
std::shared_ptr<NativeModule>* shared_this);
2017-11-20 21:34:04 +00:00
std::unique_ptr<WasmCode> AddCodeWithCodeSpace(
int index, const CodeDesc& desc, int stack_slots,
int tagged_parameter_slots,
Reland "[wasm] Further reduce the size of WasmCode" This is a reland of 79398ab09d0623100d748ef17ab618d5c0c9e6a4 Original change's description: > [wasm] Further reduce the size of WasmCode > > Also, save dynamic allocations (plus their memory overhead). > This is realized by storing the relocation information, source position > table, and protected instruction information together in one "metadata" > byte array. > For each of the three components, we just store their size, such that > the accessors can return the respecitive {Vector} views as before. > > This makes each WasmCode object 24 bytes smaller on 64-bit > architectures. It also saves a few more bytes per code object because > less padding is needed for the individual allocations, and each dynamic > allocation comes with some constant memory overhead. > > Since the protected instructions will just be stored in a byte array > now, some APIs are refactored to just return that byte array directly > (instead of an array of {ProtectedInstructionData}). This also > simplifies serialization and deserialization, and will allow for > switching to a more compact representation in the future. > > Drive-by: Add some more checks to {Vector::cast} to protect against > undefined behaviour. > > R=ahaas@chromium.org > > Bug: v8:10254 > Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66596} Tbr: ahaas@chromium.org Bug: v8:10254 Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66598}
2020-03-05 15:35:20 +00:00
Vector<const byte> protected_instructions_data,
Vector<const byte> source_position_table, WasmCode::Kind kind,
ExecutionTier tier, ForDebugging for_debugging,
Vector<uint8_t> code_space, const JumpTablesRef& jump_tables_ref);
WasmCode* CreateEmptyJumpTableInRegion(
int jump_table_size, base::AddressRegion,
const WasmCodeAllocator::OptionalLock&);
2018-06-19 09:47:17 +00:00
// Hold the {allocation_mutex_} when calling one of these methods.
// {slot_index} is the index in the declared functions, i.e. function index
// minus the number of imported functions.
void PatchJumpTablesLocked(uint32_t slot_index, Address target);
void PatchJumpTableLocked(const CodeSpaceData&, uint32_t slot_index,
Address target);
// Called by the {WasmCodeAllocator} to register a new code space.
void AddCodeSpace(base::AddressRegion,
const WasmCodeAllocator::OptionalLock&);
// Hold the {allocation_mutex_} when calling {PublishCodeLocked}.
WasmCode* PublishCodeLocked(std::unique_ptr<WasmCode>);
// {WasmCodeAllocator} manages all code reservations and allocations for this
// {NativeModule}.
WasmCodeAllocator code_allocator_;
// Features enabled for this module. We keep a copy of the features that
// were enabled at the time of the creation of this native module,
// to be consistent across asynchronous compilations later.
const WasmFeatures enabled_features_;
Reland "[wasm] Decouple background compile jobs from NativeModule" This is a reland of 92d9b09c0e68382d1427ad25c70db016bb9e5b80. Patch unchanged, errors fixed by https://crrev.com/c/1430059. Original change's description: > [wasm] Decouple background compile jobs from NativeModule > > Background compile jobs should not keep the NativeModule alive, for two > reasons: > 1) We sometimes have to wait for background compilation to finish (from > a foreground task!). This introduces unnecessary latency. > 2) Giving the background compile tasks shared ownership of the > NativeModule causes the NativeModule (and the CompilationState) to > be freed from background tasks, which is error-prone (see > https://crrev.com/c/1400420). > > Instead, this CL introduces a BackgroundCompileToken which is held > alive by the NativeModule and all background compile jobs. The initial > and the final phase of compilation (getting and submitting work) > synchronize on this token to check and ensure that the NativeModule is > and stays alive. During compilation itself, the mutex is released, such > that the NativeModule can die. > The destructor of the NativeModule cancels the BackgroundCompileToken. > Immediately afterwards, the NativeModule and the CompilationState can > die. > > This change allows to remove two hacks introduced previously: The atomic > {aborted_} flag and the {FreeCallbacksTask}. > > R=mstarzinger@chromium.org > CC=titzer@chromium.org > > Bug: v8:8689, v8:7921 > Change-Id: I42e06eab3c944b0988286f2ce18e3c294535dfb6 > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel > Reviewed-on: https://chromium-review.googlesource.com/c/1421364 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59020} TBR=mstarzinger@chromium.org Bug: v8:8689, v8:7921 Change-Id: Iead972ef77c8503da7246cab48e7693b176d8f02 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Reviewed-on: https://chromium-review.googlesource.com/c/1429862 Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59035}
2019-01-23 11:49:36 +00:00
// The decoded module, stored in a shared_ptr such that background compile
// tasks can keep this alive.
std::shared_ptr<const WasmModule> module_;
std::unique_ptr<WasmModuleSourceMap> source_map_;
// Wire bytes, held in a shared_ptr so they can be kept alive by the
// {WireBytesStorage}, held by background compile tasks.
std::shared_ptr<OwnedVector<const uint8_t>> wire_bytes_;
// The first allocated jump table. Always used by external calls (from JS).
// Wasm calls might use one of the other jump tables stored in
// {code_space_data_}.
WasmCode* main_jump_table_ = nullptr;
2018-06-19 09:47:17 +00:00
// The first allocated far jump table.
WasmCode* main_far_jump_table_ = nullptr;
// Lazy compile stub table, containing entries to jump to the
// {WasmCompileLazy} builtin, passing the function index.
WasmCode* lazy_compile_table_ = nullptr;
// The compilation state keeps track of compilation tasks for this module.
// Note that its destructor blocks until all tasks are finished/aborted and
// hence needs to be destructed first when this native module dies.
std::unique_ptr<CompilationState> compilation_state_;
// A cache of the import wrappers, keyed on the kind and signature.
std::unique_ptr<WasmImportWrapperCache> import_wrapper_cache_;
// This mutex protects concurrent calls to {AddCode} and friends.
mutable base::Mutex allocation_mutex_;
//////////////////////////////////////////////////////////////////////////////
// Protected by {allocation_mutex_}:
// Holds all allocated code objects. For lookup based on pc, the key is the
// instruction start address of the value.
std::map<Address, std::unique_ptr<WasmCode>> owned_code_;
// Table of the latest code object per function, updated on initial
// compilation and tier up. The number of entries is
// {WasmModule::num_declared_functions}, i.e. there are no entries for
// imported functions.
std::unique_ptr<WasmCode*[]> code_table_;
// Data (especially jump table) per code space.
std::vector<CodeSpaceData> code_space_data_;
// Debug information for this module. You only need to hold the allocation
// mutex while getting the {DebugInfo} pointer, or initializing this field.
// Further accesses to the {DebugInfo} do not need to be protected by the
// mutex.
std::unique_ptr<DebugInfo> debug_info_;
TieringState tiering_state_ = kTieredUp;
// End of fields protected by {allocation_mutex_}.
//////////////////////////////////////////////////////////////////////////////
WasmEngine* const engine_;
int modification_scope_depth_ = 0;
UseTrapHandler use_trap_handler_ = kNoTrapHandler;
bool lazy_compile_frozen_ = false;
DISALLOW_COPY_AND_ASSIGN(NativeModule);
2017-11-20 21:34:04 +00:00
};
class V8_EXPORT_PRIVATE WasmCodeManager final {
public:
Reland x6 [arraybuffer] Rearchitect backing store ownership This reverts commit 9da3483136b5e71e830ed9a9c34802ad8d605e58 Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5aeba9ceb13f8bfc401c5ba2521c2207ffb > > Contributed by titzer@chromium.org > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=yangguo@chromium.org Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63617}
2019-09-09 10:19:34 +00:00
explicit WasmCodeManager(size_t max_committed);
2017-11-20 21:34:04 +00:00
#ifdef DEBUG
~WasmCodeManager() {
// No more committed code space.
DCHECK_EQ(0, total_committed_code_space_.load());
}
#endif
Unwind V8 frames correctly on Windows ARM64 On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63002}
2019-07-27 06:36:52 +00:00
#if defined(V8_OS_WIN64)
Reland "Generate unwind info on Win/x64 by default" The original CL title was updated to reflect CL contents. The --win64-unwinding-info flag still exists but it is set by default. This is a reland of efd8c2d9752c4206966dfd72e4794e025b9843e1 Original change's description: > Remove --win64-unwinding-info flag and always generate unwind info on Win/x64 > > The generation of unwind info to enable stack walking on Windows/x64 > (https://chromium-review.googlesource.com/c/v8/v8/+/1469329) was implemented > behind a temporary flag, in order to coordinate these changes with the > corresponding changes in Chromium. > > The required changes to Chromium > (https://chromium-review.googlesource.com/c/chromium/src/+/1474703) have also > been merged, so we can now remove the flag and enable the generation of stack > unwinding info by default on Windows/x64. > > Bug: v8:3598 > Change-Id: I88814aaeabecc007f5262227aa0681a1d16156d5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1573138 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#61020} Bug: v8:3598, chromium:958035 Change-Id: Ie53b39f3bb31567797a61e5110685284c266c1f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599596 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#61368}
2019-04-24 22:01:00 +00:00
bool CanRegisterUnwindInfoForNonABICompliantCodeRange() const;
Unwind V8 frames correctly on Windows ARM64 On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63002}
2019-07-27 06:36:52 +00:00
#endif // V8_OS_WIN64
Reland "Generate unwind info on Win/x64 by default" The original CL title was updated to reflect CL contents. The --win64-unwinding-info flag still exists but it is set by default. This is a reland of efd8c2d9752c4206966dfd72e4794e025b9843e1 Original change's description: > Remove --win64-unwinding-info flag and always generate unwind info on Win/x64 > > The generation of unwind info to enable stack walking on Windows/x64 > (https://chromium-review.googlesource.com/c/v8/v8/+/1469329) was implemented > behind a temporary flag, in order to coordinate these changes with the > corresponding changes in Chromium. > > The required changes to Chromium > (https://chromium-review.googlesource.com/c/chromium/src/+/1474703) have also > been merged, so we can now remove the flag and enable the generation of stack > unwinding info by default on Windows/x64. > > Bug: v8:3598 > Change-Id: I88814aaeabecc007f5262227aa0681a1d16156d5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1573138 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#61020} Bug: v8:3598, chromium:958035 Change-Id: Ie53b39f3bb31567797a61e5110685284c266c1f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599596 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#61368}
2019-04-24 22:01:00 +00:00
2018-06-19 09:47:17 +00:00
NativeModule* LookupNativeModule(Address pc) const;
2017-11-20 21:34:04 +00:00
WasmCode* LookupCode(Address pc) const;
size_t committed_code_space() const {
return total_committed_code_space_.load();
}
2017-11-20 21:34:04 +00:00
// Estimate the needed code space for a Liftoff function based on the size of
// the function body (wasm byte code).
static size_t EstimateLiftoffCodeSize(int body_size);
// Estimate the needed code space from a completely decoded module.
static size_t EstimateNativeModuleCodeSize(const WasmModule* module,
bool include_liftoff);
// Estimate the needed code space from the number of functions and total code
// section length.
static size_t EstimateNativeModuleCodeSize(int num_functions,
int num_imported_functions,
int code_section_length,
bool include_liftoff);
// Estimate the size of meta data needed for the NativeModule, excluding
// generated code. This data still be stored on the C++ heap.
static size_t EstimateNativeModuleMetaDataSize(const WasmModule* module);
2017-11-20 21:34:04 +00:00
private:
friend class WasmCodeAllocator;
friend class WasmEngine;
std::shared_ptr<NativeModule> NewNativeModule(
WasmEngine* engine, Isolate* isolate,
const WasmFeatures& enabled_features, size_t code_size_estimate,
std::shared_ptr<const WasmModule> module);
2017-11-20 21:34:04 +00:00
V8_WARN_UNUSED_RESULT VirtualMemory TryAllocate(size_t size,
void* hint = nullptr);
bool Commit(base::AddressRegion);
void Decommit(base::AddressRegion);
2017-11-20 21:34:04 +00:00
void FreeNativeModule(Vector<VirtualMemory> owned_code,
size_t committed_size);
void AssignRange(base::AddressRegion, NativeModule*);
2017-11-20 21:34:04 +00:00
const size_t max_committed_code_space_;
Reland "Generate unwind info on Win/x64 by default" The original CL title was updated to reflect CL contents. The --win64-unwinding-info flag still exists but it is set by default. This is a reland of efd8c2d9752c4206966dfd72e4794e025b9843e1 Original change's description: > Remove --win64-unwinding-info flag and always generate unwind info on Win/x64 > > The generation of unwind info to enable stack walking on Windows/x64 > (https://chromium-review.googlesource.com/c/v8/v8/+/1469329) was implemented > behind a temporary flag, in order to coordinate these changes with the > corresponding changes in Chromium. > > The required changes to Chromium > (https://chromium-review.googlesource.com/c/chromium/src/+/1474703) have also > been merged, so we can now remove the flag and enable the generation of stack > unwinding info by default on Windows/x64. > > Bug: v8:3598 > Change-Id: I88814aaeabecc007f5262227aa0681a1d16156d5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1573138 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#61020} Bug: v8:3598, chromium:958035 Change-Id: Ie53b39f3bb31567797a61e5110685284c266c1f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599596 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#61368}
2019-04-24 22:01:00 +00:00
std::atomic<size_t> total_committed_code_space_{0};
// If the committed code space exceeds {critical_committed_code_space_}, then
// we trigger a GC before creating the next module. This value is set to the
// currently committed space plus 50% of the available code space on creation
// and updated after each GC.
std::atomic<size_t> critical_committed_code_space_;
mutable base::Mutex native_modules_mutex_;
//////////////////////////////////////////////////////////////////////////////
// Protected by {native_modules_mutex_}:
2017-11-20 21:34:04 +00:00
std::map<Address, std::pair<Address, NativeModule*>> lookup_map_;
// End of fields protected by {native_modules_mutex_}.
//////////////////////////////////////////////////////////////////////////////
DISALLOW_COPY_AND_ASSIGN(WasmCodeManager);
2017-11-20 21:34:04 +00:00
};
// Within the scope, the native_module is writable and not executable.
// At the scope's destruction, the native_module is executable and not writable.
// The states inside the scope and at the scope termination are irrespective of
// native_module's state when entering the scope.
// We currently mark the entire module's memory W^X:
// - for AOT, that's as efficient as it can be.
// - for Lazy, we don't have a heuristic for functions that may need patching,
// and even if we did, the resulting set of pages may be fragmented.
// Currently, we try and keep the number of syscalls low.
// - similar argument for debug time.
class NativeModuleModificationScope final {
public:
explicit NativeModuleModificationScope(NativeModule* native_module);
~NativeModuleModificationScope();
private:
NativeModule* native_module_;
};
// {WasmCodeRefScope}s form a perfect stack. New {WasmCode} pointers generated
// by e.g. creating new code or looking up code by its address are added to the
// top-most {WasmCodeRefScope}.
class V8_EXPORT_PRIVATE WasmCodeRefScope {
public:
WasmCodeRefScope();
~WasmCodeRefScope();
// Register a {WasmCode} reference in the current {WasmCodeRefScope}. Fails if
// there is no current scope.
static void AddRef(WasmCode*);
private:
WasmCodeRefScope* const previous_scope_;
std::unordered_set<WasmCode*> code_ptrs_;
DISALLOW_COPY_AND_ASSIGN(WasmCodeRefScope);
};
// Similarly to a global handle, a {GlobalWasmCodeRef} stores a single
// ref-counted pointer to a {WasmCode} object.
class GlobalWasmCodeRef {
public:
explicit GlobalWasmCodeRef(WasmCode* code,
std::shared_ptr<NativeModule> native_module)
: code_(code), native_module_(std::move(native_module)) {
code_->IncRef();
}
~GlobalWasmCodeRef() { WasmCode::DecrementRefCount({&code_, 1}); }
// Get a pointer to the contained {WasmCode} object. This is only guaranteed
// to exist as long as this {GlobalWasmCodeRef} exists.
WasmCode* code() const { return code_; }
private:
WasmCode* const code_;
// Also keep the {NativeModule} alive.
const std::shared_ptr<NativeModule> native_module_;
DISALLOW_COPY_AND_ASSIGN(GlobalWasmCodeRef);
};
const char* GetRuntimeStubName(WasmCode::RuntimeStubId);
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
} // namespace wasm
} // namespace internal
} // namespace v8
#endif // V8_WASM_WASM_CODE_MANAGER_H_