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

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

427 lines
17 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>
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"
2017-11-20 21:34:04 +00:00
#include "src/handles.h"
#include "src/trap-handler/trap-handler.h"
Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" This reverts commit ee5c31f3354ecd42a99e45a153061bc8b7a0a980. Reason for revert: Fixed compiler failure Original change's description: > Revert "[wasm] A simple allocator datastructure for off-the heap" > > This reverts commit 110d9ab0052f9c70c0c44e9c30397789568bbebf. > > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607 > > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different? > > Original change's description: > > [wasm] A simple allocator datastructure for off-the heap > > > > We'll use this allocator in a follow-up CL to: > > - allocate speculative sizes of memory for a module that's being > > compiled (e.g. 2*size of wasm code). > > - each module will own such a sub-pool, and then use it to allocate > > contiguous chunks of memory for code. > > > > The underlying assumptions for the chosen allocation strategy is that: > > - the allocation granularity for pools is 1 page, so that no one page > > is owned by more than one wasm module > > - typical pool sizes (given module sizes) are multiple pages. > > - modules and module instances are typically few and long lived. Typically, > > we expect one module and one instance. > > > > This means we shouldn't expect fragmentations that lead to code being > > non-allocatable, or prohibitively many ranges. > > > > The data structure just manages ranges of addresses. Virtual memory management > > will be separate, as part of the responsibility of a "WasmHeap" > > that will be introduced in the future. So will concurrency control. > > > > Bug: > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39 > > Reviewed-on: https://chromium-review.googlesource.com/669296 > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > > Reviewed-by: Eric Holk <eholk@chromium.org> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48053} > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org > > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://chromium-review.googlesource.com/670141 > Reviewed-by: Mircea Trofin <mtrofin@chromium.org> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48054} TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/670142 Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Reviewed-by: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:22:38 +00:00
#include "src/vector.h"
#include "src/wasm/module-compiler.h"
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 {
2017-11-20 21:34:04 +00:00
class Isolate;
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 internal {
2017-11-20 21:34:04 +00:00
struct CodeDesc;
class Code;
class WasmCompiledModule;
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;
2017-11-20 21:34:04 +00:00
struct WasmModule;
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
// Sorted, disjoint and non-overlapping memory ranges. A range is of the
// form [start, end). So there's no [start, end), [end, other_end),
// because that should have been reduced to [start, other_end).
using AddressRange = std::pair<Address, Address>;
class V8_EXPORT_PRIVATE DisjointAllocationPool final {
public:
enum ExtractionMode : bool { kAny = false, kContiguous = true };
DisjointAllocationPool() {}
explicit DisjointAllocationPool(Address, Address);
DisjointAllocationPool(DisjointAllocationPool&& other) = default;
DisjointAllocationPool& operator=(DisjointAllocationPool&& other) = default;
// Merge the ranges of the parameter into this object. Ordering is
// preserved. The assumption is that the passed parameter is
// not intersecting this object - for example, it was obtained
// from a previous Allocate{Pool}.
void Merge(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
// Allocate a contiguous range of size {size}. Return an empty pool on
// failure.
DisjointAllocationPool Allocate(size_t size) {
return Extract(size, kContiguous);
}
// Allocate a sub-pool of size {size}. Return an empty pool on failure.
DisjointAllocationPool AllocatePool(size_t size) {
return Extract(size, kAny);
}
bool IsEmpty() const { return ranges_.empty(); }
const std::list<AddressRange>& ranges() const { return ranges_; }
private:
// Extract out a total of {size}. By default, the return may
// be more than one range. If kContiguous is passed, the return
// will be one range. If the operation fails, this object is
// unchanged, and the return {IsEmpty()}
DisjointAllocationPool Extract(size_t size, ExtractionMode mode);
std::list<AddressRange> ranges_;
DISALLOW_COPY_AND_ASSIGN(DisjointAllocationPool)
};
2017-11-20 21:34:04 +00:00
using ProtectedInstructions =
std::vector<trap_handler::ProtectedInstructionData>;
class V8_EXPORT_PRIVATE WasmCode final {
public:
enum Kind {
kFunction,
kWasmToJsWrapper,
kLazyStub,
kInterpreterStub,
kTrampoline
2017-11-20 21:34:04 +00:00
};
// 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());
}
2017-11-20 21:34:04 +00:00
Vector<const byte> reloc_info() const {
return {reloc_info_.get(), reloc_size_};
}
Vector<const byte> source_positions() const {
return {source_position_table_.get(), source_position_size_};
}
2017-11-20 21:34:04 +00:00
uint32_t index() const { return index_.ToChecked(); }
// Anonymous functions are functions that don't carry an index, like
// trampolines.
bool IsAnonymous() const { return index_.IsNothing(); }
Kind kind() const { return kind_; }
NativeModule* native_module() const { return native_module_; }
Tier tier() const { return tier_; }
2017-11-20 21:34:04 +00:00
Address constant_pool() const;
size_t constant_pool_offset() const { return constant_pool_offset_; }
size_t safepoint_table_offset() const { return safepoint_table_offset_; }
size_t handler_table_offset() const { return handler_table_offset_; }
2017-11-20 21:34:04 +00:00
uint32_t stack_slots() const { return stack_slots_; }
bool is_liftoff() const { return tier_ == kLiftoff; }
2017-11-20 21:34:04 +00:00
const ProtectedInstructions& protected_instructions() const {
// TODO(mstarzinger): Code that doesn't have trapping instruction should
// not be required to have this vector, make it possible to be null.
DCHECK_NOT_NULL(protected_instructions_);
2017-11-20 21:34:04 +00:00
return *protected_instructions_.get();
}
// Register protected instruction information with the trap handler. Sets
// trap_handler_index.
void RegisterTrapHandlerData();
2017-11-20 21:34:04 +00:00
void Print(Isolate* isolate) const;
void Disassemble(const char* name, Isolate* isolate, 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 };
// Offset of {instructions_.start()}. It is used for tiering, when
// we check if optimized code is available during the prologue
// of Liftoff-compiled code.
static constexpr int kInstructionStartOffset = 0;
2017-11-20 21:34:04 +00:00
private:
friend class NativeModule;
WasmCode(Vector<byte> instructions, std::unique_ptr<const byte[]> reloc_info,
size_t reloc_size, std::unique_ptr<const byte[]> source_pos,
size_t source_pos_size, NativeModule* native_module,
Maybe<uint32_t> index, Kind kind, size_t constant_pool_offset,
uint32_t stack_slots, size_t safepoint_table_offset,
size_t handler_table_offset,
std::unique_ptr<ProtectedInstructions> protected_instructions,
Tier tier)
2017-11-20 21:34:04 +00:00
: instructions_(instructions),
reloc_info_(std::move(reloc_info)),
reloc_size_(reloc_size),
source_position_table_(std::move(source_pos)),
source_position_size_(source_pos_size),
native_module_(native_module),
2017-11-20 21:34:04 +00:00
index_(index),
kind_(kind),
constant_pool_offset_(constant_pool_offset),
stack_slots_(stack_slots),
safepoint_table_offset_(safepoint_table_offset),
handler_table_offset_(handler_table_offset),
protected_instructions_(std::move(protected_instructions)),
tier_(tier) {
DCHECK_LE(safepoint_table_offset, instructions.size());
DCHECK_LE(constant_pool_offset, instructions.size());
DCHECK_LE(handler_table_offset, instructions.size());
DCHECK_EQ(kInstructionStartOffset, OFFSET_OF(WasmCode, instructions_));
}
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;
void ResetTrapHandlerIndex();
2017-11-20 21:34:04 +00:00
Vector<byte> instructions_;
std::unique_ptr<const byte[]> reloc_info_;
size_t reloc_size_ = 0;
std::unique_ptr<const byte[]> source_position_table_;
size_t source_position_size_ = 0;
NativeModule* native_module_ = nullptr;
2017-11-20 21:34:04 +00:00
Maybe<uint32_t> index_;
Kind kind_;
size_t constant_pool_offset_ = 0;
uint32_t stack_slots_ = 0;
// we care about safepoint data for wasm-to-js functions,
// since there may be stack/register tagged values for large number
// conversions.
size_t safepoint_table_offset_ = 0;
size_t handler_table_offset_ = 0;
2017-11-20 21:34:04 +00:00
intptr_t trap_handler_index_ = -1;
std::unique_ptr<ProtectedInstructions> 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
// Note that we currently need to add code on the main thread, because we may
// trigger a GC if we believe there's a chance the GC would clear up native
// modules. The code is ready for concurrency otherwise, we just need to be
// careful about this GC consideration. See WouldGCHelp and
// WasmCodeManager::Commit.
class V8_EXPORT_PRIVATE NativeModule final {
public:
WasmCode* AddCode(const CodeDesc& desc, uint32_t frame_count, uint32_t index,
size_t safepoint_table_offset, size_t handler_table_offset,
std::unique_ptr<ProtectedInstructions>,
Handle<ByteArray> source_position_table,
WasmCode::Tier tier);
2017-11-20 21:34:04 +00:00
// A way to copy over JS-allocated code. This is because we compile
// certain wrappers using a different pipeline.
WasmCode* AddCodeCopy(Handle<Code> code, WasmCode::Kind kind, uint32_t index);
// Add an interpreter wrapper. For the same reason as AddCodeCopy, we
// currently compile these using a different pipeline and we can't get a
// CodeDesc here. When adding interpreter wrappers, we do not insert them in
// the code_table, however, we let them self-identify as the {index} function
WasmCode* AddInterpreterWrapper(Handle<Code> code, uint32_t index);
// When starting lazy compilation, provide the WasmLazyCompile builtin by
// calling SetLazyBuiltin. It will initialize the code table with it. Copies
// of it might be cloned from them later when creating entries for exported
2017-11-20 21:34:04 +00:00
// functions and indirect callable functions, so that they may be identified
// by the runtime.
void SetLazyBuiltin(Handle<Code> code);
2017-11-20 21:34:04 +00:00
// FunctionCount is WasmModule::functions.size().
uint32_t FunctionCount() const;
WasmCode* GetCode(uint32_t index) const;
void SetCode(uint32_t index, WasmCode* wasm_code);
2017-11-20 21:34:04 +00:00
// Register/release the protected instructions in all code objects with the
// global trap handler for this process.
void UnpackAndRegisterProtectedInstructions();
void ReleaseProtectedInstructions();
// Gets code suitable for indirect or import calls for the given function
// index. If the code at the given index is the lazy compile stub, it will
// clone a non-anonymous lazy compile stub for the purpose.
WasmCode* GetIndirectlyCallableCode(uint32_t func_index);
2017-11-20 21:34:04 +00:00
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 ResizeCodeTableForTesting(size_t num_functions, size_t max_functions);
2017-11-20 21:34:04 +00:00
CompilationState* compilation_state() { return compilation_state_.get(); }
// TODO(mstarzinger): The link to the {shared_module_data} is deprecated and
// all uses should vanish to make {NativeModule} independent of the Isolate.
WasmSharedModuleData* shared_module_data() const;
void SetSharedModuleData(Handle<WasmSharedModuleData>);
2017-11-20 21:34:04 +00:00
uint32_t num_imported_functions() const { return num_imported_functions_; }
const std::vector<WasmCode*>& code_table() const { return code_table_; }
2017-11-20 21:34:04 +00:00
size_t committed_memory() const { return committed_memory_; }
bool use_trap_handler() const { return use_trap_handler_; }
void set_lazy_compile_frozen(bool frozen) { lazy_compile_frozen_ = frozen; }
bool lazy_compile_frozen() const { return lazy_compile_frozen_; }
2017-11-20 21:34:04 +00:00
const size_t instance_id = 0;
~NativeModule();
private:
friend class WasmCodeManager;
friend class NativeModuleSerializer;
friend class NativeModuleDeserializer;
friend class NativeModuleModificationScope;
2017-11-20 21:34:04 +00:00
struct AddressHasher {
size_t operator()(const Address& addr) const {
return std::hash<Address>()(addr);
}
};
static base::AtomicNumber<size_t> next_id_;
2017-11-20 21:34:04 +00:00
NativeModule(uint32_t num_functions, uint32_t num_imports,
bool can_request_more, VirtualMemory* vmem,
WasmCodeManager* code_manager, ModuleEnv& env);
2017-11-20 21:34:04 +00:00
WasmCode* AddAnonymousCode(Handle<Code>, WasmCode::Kind kind);
Address AllocateForCode(size_t size);
// Primitive for adding code to the native module. All code added to a native
// module is owned by that module. Various callers get to decide on how the
// code is obtained (CodeDesc vs, as a point in time, Code*), the kind,
// whether it has an index or is anonymous, etc.
WasmCode* AddOwnedCode(Vector<const byte> orig_instructions,
std::unique_ptr<const byte[]> reloc_info,
size_t reloc_size,
std::unique_ptr<const byte[]> source_pos,
size_t source_pos_size, Maybe<uint32_t> index,
2017-11-20 21:34:04 +00:00
WasmCode::Kind kind, size_t constant_pool_offset,
uint32_t stack_slots, size_t safepoint_table_offset,
size_t handler_table_offset,
std::unique_ptr<ProtectedInstructions>, WasmCode::Tier,
WasmCode::FlushICache);
WasmCode* CloneCode(const WasmCode*, WasmCode::FlushICache);
2017-11-20 21:34:04 +00:00
WasmCode* Lookup(Address);
Address GetLocalAddressFor(Handle<Code>);
Address CreateTrampolineTo(Handle<Code>);
// Holds all allocated code objects, is maintained to be in ascending order
// according to the codes instruction start address to allow lookups.
2017-11-20 21:34:04 +00:00
std::vector<std::unique_ptr<WasmCode>> owned_code_;
std::vector<WasmCode*> code_table_;
std::unique_ptr<std::vector<WasmCode*>> lazy_compile_stubs_;
2017-11-20 21:34:04 +00:00
uint32_t num_imported_functions_;
// Maps from instruction start of an immovable code object to instruction
// start of the trampoline.
2017-11-20 21:34:04 +00:00
std::unordered_map<Address, Address, AddressHasher> trampolines_;
std::unique_ptr<CompilationState, CompilationStateDeleter> compilation_state_;
// A phantom reference to the {WasmSharedModuleData}. It is intentionally not
// typed {Handle<WasmSharedModuleData>} because this location will be cleared
// when the phantom reference is cleared.
WasmSharedModuleData** shared_module_data_ = nullptr;
2017-11-20 21:34:04 +00:00
DisjointAllocationPool free_memory_;
DisjointAllocationPool allocated_memory_;
std::list<VirtualMemory> owned_memory_;
WasmCodeManager* wasm_code_manager_;
base::Mutex allocation_mutex_;
size_t committed_memory_ = 0;
int modification_scope_depth_ = 0;
2017-11-20 21:34:04 +00:00
bool can_request_more_memory_;
bool use_trap_handler_;
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:
// The only reason we depend on Isolate is to report native memory used
// and held by a GC-ed object. We'll need to mitigate that when we
// start sharing wasm heaps.
WasmCodeManager(v8::Isolate*, size_t max_committed);
// Create a new NativeModule. The caller is responsible for its
// lifetime. The native module will be given some memory for code,
// which will be page size aligned. The size of the initial memory
// is determined with a heuristic based on the total size of wasm
// code. The native module may later request more memory.
std::unique_ptr<NativeModule> NewNativeModule(const WasmModule& module,
ModuleEnv& env);
2017-11-20 21:34:04 +00:00
std::unique_ptr<NativeModule> NewNativeModule(size_t memory_estimate,
uint32_t num_functions,
uint32_t num_imported_functions,
bool can_request_more,
ModuleEnv& env);
2017-11-20 21:34:04 +00:00
WasmCode* LookupCode(Address pc) const;
WasmCode* GetCodeFromStartAddress(Address pc) const;
intptr_t remaining_uncommitted() const;
private:
friend class NativeModule;
void TryAllocate(size_t size, VirtualMemory*, void* hint = nullptr);
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 FreeNativeModuleMemories.
// There's no separate Uncommit.
void FreeNativeModuleMemories(NativeModule*);
void Free(VirtualMemory* mem);
void AssignRanges(Address start, Address end, NativeModule*);
2017-11-20 21:34:04 +00:00
size_t GetAllocationChunk(const WasmModule& module);
bool WouldGCHelp() const;
std::map<Address, std::pair<Address, NativeModule*>> lookup_map_;
// count of NativeModules not yet collected. Helps determine if it's
// worth requesting a GC on memory pressure.
size_t active_ = 0;
base::AtomicNumber<intptr_t> remaining_uncommitted_;
// TODO(mtrofin): remove the dependency on isolate.
2017-11-20 21:34:04 +00:00
v8::Isolate* isolate_;
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_