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

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

511 lines
20 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
2017-11-20 21:34:04 +00:00
#include <functional>
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 <list>
2017-11-20 21:34:04 +00:00
#include <map>
#include <unordered_map>
#include <unordered_set>
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/builtins/builtins-definitions.h"
2017-11-20 21:34:04 +00:00
#include "src/handles.h"
#include "src/trap-handler/trap-handler.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/vector.h"
#include "src/wasm/module-compiler.h"
#include "src/wasm/wasm-features.h"
#include "src/wasm/wasm-limits.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
struct CodeDesc;
class Code;
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 {
2017-11-20 21:34:04 +00:00
class NativeModule;
class WasmCodeManager;
class WasmMemoryTracker;
2017-11-20 21:34:04 +00:00
struct WasmModule;
// 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:
DisjointAllocationPool() = default;
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
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
DisjointAllocationPool(DisjointAllocationPool&& other) = default;
DisjointAllocationPool& operator=(DisjointAllocationPool&& other) = default;
// Merge the parameter region into this object while preserving ordering of
// the regions. The assumption is that the passed parameter is not
// intersecting this object - for example, it was obtained from a previous
// Allocate.
void 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
bool IsEmpty() const { return regions_.empty(); }
const std::list<base::AddressRegion>& 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::list<base::AddressRegion> 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
DISALLOW_COPY_AND_ASSIGN(DisjointAllocationPool)
};
2017-11-20 21:34:04 +00:00
class V8_EXPORT_PRIVATE WasmCode final {
public:
enum Kind {
kFunction,
kWasmToJsWrapper,
kLazyStub,
kRuntimeStub,
kInterpreterEntry,
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
};
// kOther is used if we have WasmCode that is neither
// liftoff- nor turbofan-compiled, i.e. if Kind is
// not a kFunction.
enum Tier : int8_t { kLiftoff, kTurbofan, kOther };
2017-11-20 21:34:04 +00:00
Vector<byte> instructions() const { return instructions_; }
Address instruction_start() const {
return reinterpret_cast<Address>(instructions_.start());
}
Vector<const byte> reloc_info() const { return reloc_info_.as_vector(); }
Vector<const byte> source_positions() const {
return source_position_table_.as_vector();
}
2017-11-20 21:34:04 +00:00
uint32_t index() const {
DCHECK(!IsAnonymous());
return index_;
}
// Anonymous functions are functions that don't carry an index.
bool IsAnonymous() const { return index_ == kAnonymousFuncIndex; }
2017-11-20 21:34:04 +00:00
Kind kind() const { return kind_; }
NativeModule* native_module() const { return native_module_; }
Tier tier() const { return tier_; }
2017-11-20 21:34:04 +00:00
Address constant_pool() const;
size_t constant_pool_offset() const { return constant_pool_offset_; }
size_t safepoint_table_offset() const { return safepoint_table_offset_; }
size_t handler_table_offset() const { return handler_table_offset_; }
2017-11-20 21:34:04 +00:00
uint32_t stack_slots() const { return stack_slots_; }
bool is_liftoff() const { return tier_ == kLiftoff; }
bool contains(Address pc) const {
return reinterpret_cast<Address>(instructions_.start()) <= pc &&
pc < reinterpret_cast<Address>(instructions_.end());
}
2017-11-20 21:34:04 +00:00
Vector<trap_handler::ProtectedInstructionData> protected_instructions()
const {
return protected_instructions_.as_vector();
2017-11-20 21:34:04 +00:00
}
void Validate() const;
void Print(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();
enum FlushICache : bool { kFlushICache = true, kNoFlushICache = false };
2017-11-20 21:34:04 +00:00
private:
friend class NativeModule;
WasmCode(NativeModule* native_module, uint32_t index,
Vector<byte> instructions, uint32_t stack_slots,
size_t safepoint_table_offset, size_t handler_table_offset,
size_t constant_pool_offset,
OwnedVector<trap_handler::ProtectedInstructionData>
protected_instructions,
OwnedVector<const byte> reloc_info,
OwnedVector<const byte> source_position_table, Kind kind, Tier tier)
2017-11-20 21:34:04 +00:00
: instructions_(instructions),
reloc_info_(std::move(reloc_info)),
source_position_table_(std::move(source_position_table)),
native_module_(native_module),
2017-11-20 21:34:04 +00:00
index_(index),
kind_(kind),
constant_pool_offset_(constant_pool_offset),
stack_slots_(stack_slots),
safepoint_table_offset_(safepoint_table_offset),
handler_table_offset_(handler_table_offset),
protected_instructions_(std::move(protected_instructions)),
tier_(tier) {
DCHECK_LE(safepoint_table_offset, instructions.size());
DCHECK_LE(constant_pool_offset, instructions.size());
DCHECK_LE(handler_table_offset, instructions.size());
}
2017-11-20 21:34:04 +00:00
// Code objects that have been registered with the global trap handler within
// this process, will have a {trap_handler_index} associated with them.
size_t trap_handler_index() const;
void set_trap_handler_index(size_t);
bool HasTrapHandlerIndex() const;
// Register protected instruction information with the trap handler. Sets
// trap_handler_index.
void RegisterTrapHandlerData();
static constexpr uint32_t kAnonymousFuncIndex = 0xffffffff;
STATIC_ASSERT(kAnonymousFuncIndex > kV8MaxWasmFunctions);
2017-11-20 21:34:04 +00:00
Vector<byte> instructions_;
OwnedVector<const byte> reloc_info_;
OwnedVector<const byte> source_position_table_;
NativeModule* native_module_ = nullptr;
uint32_t index_;
2017-11-20 21:34:04 +00:00
Kind kind_;
size_t constant_pool_offset_ = 0;
uint32_t stack_slots_ = 0;
// we care about safepoint data for wasm-to-js functions,
// since there may be stack/register tagged values for large number
// conversions.
size_t safepoint_table_offset_ = 0;
size_t handler_table_offset_ = 0;
2017-11-20 21:34:04 +00:00
intptr_t trap_handler_index_ = -1;
OwnedVector<trap_handler::ProtectedInstructionData> protected_instructions_;
Tier tier_;
DISALLOW_COPY_AND_ASSIGN(WasmCode);
2017-11-20 21:34:04 +00:00
};
// Return a textual description of the kind.
const char* GetWasmCodeKindAsString(WasmCode::Kind);
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 kCanAllocateMoreMemory = false;
#else
static constexpr bool kCanAllocateMoreMemory = true;
#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.
WasmCode* AddCode(uint32_t index, const CodeDesc& desc, uint32_t stack_slots,
size_t safepoint_table_offset, size_t handler_table_offset,
OwnedVector<trap_handler::ProtectedInstructionData>
protected_instructions,
OwnedVector<const byte> source_position_table,
WasmCode::Tier tier);
2017-11-20 21:34:04 +00:00
WasmCode* AddDeserializedCode(
uint32_t index, Vector<const byte> instructions, uint32_t stack_slots,
size_t safepoint_table_offset, size_t handler_table_offset,
size_t constant_pool_offset,
OwnedVector<trap_handler::ProtectedInstructionData>
protected_instructions,
OwnedVector<const byte> reloc_info,
OwnedVector<const byte> source_position_table, WasmCode::Tier tier);
// Add an import wrapper for wasm-to-JS transitions. This method copies over
// JS-allocated code, because we compile wrappers using a different pipeline.
WasmCode* AddImportWrapper(Handle<Code> code, uint32_t index);
2017-11-20 21:34:04 +00:00
// Add an interpreter entry. For the same reason as AddImportWrapper, we
2017-11-20 21:34:04 +00:00
// currently compile these using a different pipeline and we can't get a
// CodeDesc here. When adding interpreter wrappers, we do not insert them in
// the code_table, however, we let them self-identify as the {index} function.
WasmCode* AddInterpreterEntry(Handle<Code> code, uint32_t index);
2017-11-20 21:34:04 +00:00
// Adds anonymous code for testing purposes.
WasmCode* AddCodeForTesting(Handle<Code> code);
2017-11-20 21:34:04 +00:00
// When starting lazy compilation, provide the WasmLazyCompile builtin by
2018-06-19 09:47:17 +00:00
// calling SetLazyBuiltin. It will be copied into this NativeModule and the
// jump table will be populated with that copy.
void SetLazyBuiltin(Handle<Code> code);
2017-11-20 21:34:04 +00:00
// Initializes all runtime stubs by copying them over from the JS-allocated
// heap into this native module. It must be called exactly once per native
// module before adding other WasmCode so that runtime stub ids can be
// resolved during relocation.
void SetRuntimeStubs(Isolate* isolate);
// Makes the code available to the system (by entering it into the code table
// and patching the jump table). Callers have to take care not to race with
// threads executing the old code.
void PublishCode(WasmCode* code);
// 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* code(uint32_t index) const {
DCHECK_LT(index, num_functions());
DCHECK_LE(module_->num_imported_functions, index);
return code_table_[index - module_->num_imported_functions];
}
bool has_code(uint32_t index) const { return code(index) != nullptr; }
WasmCode* runtime_stub(WasmCode::RuntimeStubId index) const {
DCHECK_LT(index, WasmCode::kRuntimeStubCount);
WasmCode* code = runtime_stub_table_[index];
DCHECK_NOT_NULL(code);
return code;
}
Address jump_table_start() const {
return jump_table_ ? jump_table_->instruction_start() : kNullAddress;
}
ptrdiff_t jump_table_offset(uint32_t func_index) const {
DCHECK_GE(func_index, num_imported_functions());
return GetCallTargetForFunction(func_index) - jump_table_start();
}
2018-06-19 09:47:17 +00:00
bool is_jump_table_slot(Address address) const {
return jump_table_->contains(address);
}
// Transition this module from code relying on trap handlers (i.e. without
// explicit memory bounds checks) to code that does not require trap handlers
// (i.e. code with explicit bounds checks).
// This method must only be called if {use_trap_handler()} is true (it will be
// false afterwards). All code in this {NativeModule} needs to be re-added
// after calling this method.
void DisableTrapHandler();
2018-06-19 09:47:17 +00:00
// Returns the target to call for the given function (returns a jump table
// slot within {jump_table_}).
Address GetCallTargetForFunction(uint32_t func_index) const;
2017-11-20 21:34:04 +00:00
// Reverse lookup from a given call target (i.e. a jump table slot as the
// above {GetCallTargetForFunction} returns) to a function index.
uint32_t GetFunctionIndexFromJumpTableSlot(Address slot_address) const;
bool SetExecutable(bool 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(); }
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;
}
bool 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 byte> wire_bytes() const { return wire_bytes_.as_vector(); }
void set_wire_bytes(OwnedVector<const byte> wire_bytes) {
wire_bytes_ = std::move(wire_bytes);
}
const WasmModule* module() const { return module_.get(); }
WasmCodeManager* code_manager() const { return wasm_code_manager_; }
2018-06-19 09:47:17 +00:00
WasmCode* Lookup(Address) const;
2017-11-20 21:34:04 +00:00
~NativeModule();
const WasmFeatures& enabled_features() const { return enabled_features_; }
2017-11-20 21:34:04 +00:00
private:
friend class WasmCode;
2017-11-20 21:34:04 +00:00
friend class WasmCodeManager;
friend class NativeModuleModificationScope;
2017-11-20 21:34:04 +00:00
NativeModule(Isolate* isolate, const WasmFeatures& enabled_features,
bool can_request_more, VirtualMemory code_space,
WasmCodeManager* code_manager,
std::shared_ptr<const WasmModule> module, const ModuleEnv& env);
2017-11-20 21:34:04 +00:00
WasmCode* AddAnonymousCode(Handle<Code>, WasmCode::Kind kind);
Address AllocateForCode(size_t size);
// Primitive for adding code to the native module. All code added to a native
// module is owned by that module. Various callers get to decide on how the
// code is obtained (CodeDesc vs, as a point in time, Code*), the kind,
// whether it has an index or is anonymous, etc.
WasmCode* AddOwnedCode(uint32_t index, Vector<const byte> instructions,
uint32_t stack_slots, size_t safepoint_table_offset,
size_t handler_table_offset,
size_t constant_pool_offset,
OwnedVector<trap_handler::ProtectedInstructionData>,
OwnedVector<const byte> reloc_info,
OwnedVector<const byte> source_position_table,
WasmCode::Kind, WasmCode::Tier);
2017-11-20 21:34:04 +00:00
2018-06-19 09:47:17 +00:00
WasmCode* CreateEmptyJumpTable(uint32_t num_wasm_functions);
// Hold the {allocation_mutex_} when calling this method.
void InstallCode(WasmCode* code);
2018-06-19 09:47:17 +00:00
Vector<WasmCode*> code_table() const {
return {code_table_.get(), module_->num_declared_functions};
}
// 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_;
// TODO(clemensh): Make this a unique_ptr (requires refactoring
// AsyncCompileJob).
std::shared_ptr<const WasmModule> module_;
OwnedVector<const byte> wire_bytes_;
WasmCode* runtime_stub_table_[WasmCode::kRuntimeStubCount] = {nullptr};
2017-11-20 21:34:04 +00:00
2018-06-19 09:47:17 +00:00
// Jump table used to easily redirect wasm function calls.
WasmCode* jump_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, CompilationStateDeleter> compilation_state_;
// This mutex protects concurrent calls to {AddCode} and friends.
mutable base::Mutex allocation_mutex_;
//////////////////////////////////////////////////////////////////////////////
// Protected by {allocation_mutex_}:
// Holds all allocated code objects, is maintained to be in ascending order
// according to the codes instruction start address to allow lookups.
std::vector<std::unique_ptr<WasmCode>> owned_code_;
std::unique_ptr<WasmCode* []> code_table_;
DisjointAllocationPool free_code_space_;
DisjointAllocationPool allocated_code_space_;
std::list<VirtualMemory> owned_code_space_;
// End of fields protected by {allocation_mutex_}.
//////////////////////////////////////////////////////////////////////////////
2017-11-20 21:34:04 +00:00
WasmCodeManager* wasm_code_manager_;
std::atomic<size_t> committed_code_space_{0};
int modification_scope_depth_ = 0;
2017-11-20 21:34:04 +00:00
bool can_request_more_memory_;
bool use_trap_handler_ = false;
bool is_executable_ = false;
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:
explicit WasmCodeManager(WasmMemoryTracker* memory_tracker,
size_t max_committed);
2017-11-20 21:34:04 +00:00
// Create a new NativeModule. The caller is responsible for its
// lifetime. The native module will be given some memory for code,
// which will be page size aligned. The size of the initial memory
// is determined with a heuristic based on the total size of wasm
// code. The native module may later request more memory.
// TODO(titzer): isolate is only required here for CompilationState.
std::unique_ptr<NativeModule> NewNativeModule(
Isolate* isolate, const WasmFeatures& enabled_features,
size_t memory_estimate, bool can_request_more,
std::shared_ptr<const WasmModule> module, const ModuleEnv& env);
2017-11-20 21:34:04 +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;
WasmCode* GetCodeFromStartAddress(Address pc) const;
size_t remaining_uncommitted_code_space() const;
2017-11-20 21:34:04 +00:00
// Add a sample of all module sizes.
void SampleModuleSizes(Isolate* isolate) const;
// TODO(v8:7424): For now we sample module sizes in a GC callback. This will
// bias samples towards apps with high memory pressure. We should switch to
// using sampling based on regular intervals independent of the GC.
static void InstallSamplingGCCallback(Isolate* isolate);
static size_t EstimateNativeModuleSize(const WasmModule* module);
2017-11-20 21:34:04 +00:00
private:
friend class NativeModule;
V8_WARN_UNUSED_RESULT VirtualMemory TryAllocate(size_t size,
void* hint = nullptr);
2017-11-20 21:34:04 +00:00
bool Commit(Address, size_t);
// Currently, we uncommit a whole module, so all we need is account
// for the freed memory size. We do that in FreeNativeModule.
2017-11-20 21:34:04 +00:00
// There's no separate Uncommit.
void FreeNativeModule(NativeModule*);
void AssignRanges(Address start, Address end, NativeModule*);
void AssignRangesAndAddModule(Address start, Address end, NativeModule*);
bool ShouldForceCriticalMemoryPressureNotification();
2017-11-20 21:34:04 +00:00
WasmMemoryTracker* const memory_tracker_;
std::atomic<size_t> remaining_uncommitted_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_;
std::unordered_set<NativeModule*> native_modules_;
// 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_;
};
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_