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

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

568 lines
22 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/compilation-environment.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 WasmEngine;
class WasmMemoryTracker;
class WasmImportWrapperCache;
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) V8_NOEXCEPT = default;
DisjointAllocationPool& operator=(DisjointAllocationPool&& other)
V8_NOEXCEPT = 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
// 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);
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,
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;
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;
2017-11-20 21:34:04 +00:00
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_; }
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
size_t code_comments_offset() const { return code_comments_offset_; }
size_t unpadded_binary_size() const { return unpadded_binary_size_; }
2017-11-20 21:34:04 +00:00
uint32_t stack_slots() const { return stack_slots_; }
uint32_t tagged_parameter_slots() const { return tagged_parameter_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
}
const char* GetRuntimeStubName() const;
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();
enum FlushICache : bool { kFlushICache = true, kNoFlushICache = false };
static constexpr uint32_t kAnonymousFuncIndex = 0xffffffff;
STATIC_ASSERT(kAnonymousFuncIndex > kV8MaxWasmFunctions);
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,
uint32_t tagged_parameter_slots, size_t safepoint_table_offset,
size_t handler_table_offset, size_t constant_pool_offset,
size_t code_comments_offset, size_t unpadded_binary_size,
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),
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),
protected_instructions_(std::move(protected_instructions)),
tier_(tier) {
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
// 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();
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;
// 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.
uint32_t tagged_parameter_slots_ = 0;
2017-11-20 21:34:04 +00:00
// 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;
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
size_t code_comments_offset_ = 0;
size_t unpadded_binary_size_ = 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,
uint32_t tagged_parameter_slots,
size_t safepoint_table_offset, size_t handler_table_offset,
OwnedVector<trap_handler::ProtectedInstructionData>
protected_instructions,
OwnedVector<const byte> source_position_table,
WasmCode::Kind kind, WasmCode::Tier tier);
2017-11-20 21:34:04 +00:00
WasmCode* AddDeserializedCode(
uint32_t index, Vector<const byte> instructions, uint32_t stack_slots,
uint32_t tagged_parameter_slots, size_t safepoint_table_offset,
size_t handler_table_offset, size_t constant_pool_offset,
size_t code_comments_offset, size_t unpadded_binary_size,
OwnedVector<trap_handler::ProtectedInstructionData>
protected_instructions,
OwnedVector<const byte> reloc_info,
OwnedVector<const byte> source_position_table, WasmCode::Tier tier);
// 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);
// Switch a function to an interpreter entry wrapper. When adding interpreter
// wrappers, we do not insert them in the code_table, however, we let them
// self-identify as the {index} function.
void PublishInterpreterEntry(WasmCode* code, uint32_t index);
// 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(); }
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 committed_code_space_.load(); }
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_; }
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(WasmEngine* engine, Isolate* isolate,
const WasmFeatures& enabled_features, bool can_request_more,
VirtualMemory code_space,
std::shared_ptr<const WasmModule> module);
2017-11-20 21:34:04 +00:00
WasmCode* AddAnonymousCode(Handle<Code>, WasmCode::Kind kind,
const char* name = nullptr);
// Allocate code space. Returns a valid buffer or fails with OOM (crash).
Vector<byte> AllocateForCode(size_t size);
2017-11-20 21:34:04 +00:00
// 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,
2017-11-20 21:34:04 +00:00
// whether it has an index or is anonymous, etc.
WasmCode* AddOwnedCode(uint32_t index, Vector<const byte> instructions,
uint32_t stack_slots, uint32_t tagged_parameter_slots,
size_t safepoint_table_offset,
size_t handler_table_offset,
size_t constant_pool_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
size_t code_comments_offset,
size_t unpadded_binary_size,
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};
}
// Hold the {mutex_} when calling this method.
bool has_interpreter_redirection(uint32_t func_index) {
DCHECK_LT(func_index, num_functions());
DCHECK_LE(module_->num_imported_functions, func_index);
if (!interpreter_redirections_) return false;
uint32_t bitset_idx = func_index - module_->num_imported_functions;
uint8_t byte = interpreter_redirections_[bitset_idx / kBitsPerByte];
return byte & (1 << (bitset_idx % kBitsPerByte));
}
// Hold the {mutex_} when calling this method.
void SetInterpreterRedirection(uint32_t func_index) {
DCHECK_LT(func_index, num_functions());
DCHECK_LE(module_->num_imported_functions, func_index);
if (!interpreter_redirections_) {
interpreter_redirections_.reset(
new uint8_t[RoundUp<kBitsPerByte>(module_->num_declared_functions) /
kBitsPerByte]);
}
uint32_t bitset_idx = func_index - module_->num_imported_functions;
uint8_t& byte = interpreter_redirections_[bitset_idx / kBitsPerByte];
byte |= 1 << (bitset_idx % kBitsPerByte);
}
// 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_;
// 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_;
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> 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, 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_;
// Null if no redirections exist, otherwise a bitset over all functions in
// this module marking those functions that have been redirected.
std::unique_ptr<uint8_t[]> interpreter_redirections_;
DisjointAllocationPool free_code_space_;
DisjointAllocationPool allocated_code_space_;
std::list<VirtualMemory> owned_code_space_;
// End of fields protected by {allocation_mutex_}.
//////////////////////////////////////////////////////////////////////////////
WasmEngine* const engine_;
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_;
UseTrapHandler use_trap_handler_ = kNoTrapHandler;
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
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 remaining_uncommitted_code_space() const;
2017-11-20 21:34:04 +00:00
void SetMaxCommittedMemoryForTesting(size_t limit);
static size_t EstimateNativeModuleCodeSize(const WasmModule* module);
static size_t EstimateNativeModuleNonCodeSize(const WasmModule* module);
2017-11-20 21:34:04 +00:00
private:
friend class NativeModule;
friend class WasmEngine;
std::unique_ptr<NativeModule> NewNativeModule(
WasmEngine* engine, Isolate* isolate,
const WasmFeatures& enabled_features, size_t code_size_estimate,
bool can_request_more, 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);
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*);
2017-11-20 21:34:04 +00:00
WasmMemoryTracker* const memory_tracker_;
std::atomic<size_t> remaining_uncommitted_code_space_;
// If the remaining uncommitted code space falls below
// {critical_uncommitted_code_space_}, then we trigger a GC before creating
// the next module. This value is initialized to 50% of the available code
// space on creation and after each GC.
std::atomic<size_t> critical_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_;
// 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_