v8/test/unittests/wasm/wasm-code-manager-unittest.cc

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

339 lines
12 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.
#include "test/unittests/test-utils.h"
#include "testing/gmock/include/gmock/gmock.h"
#include "src/wasm/function-compiler.h"
2018-06-19 09:47:17 +00:00
#include "src/wasm/jump-table-assembler.h"
#include "src/wasm/wasm-code-manager.h"
#include "src/wasm/wasm-engine.h"
#include "src/wasm/wasm-memory.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 {
namespace wasm {
namespace wasm_heap_unittest {
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
class DisjointAllocationPoolTest : public ::testing::Test {
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
public:
void CheckPool(const DisjointAllocationPool& mem,
std::initializer_list<base::AddressRegion> expected_regions);
void CheckRange(base::AddressRegion region1, base::AddressRegion region2);
DisjointAllocationPool Make(
std::initializer_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
};
void DisjointAllocationPoolTest::CheckPool(
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
const DisjointAllocationPool& mem,
std::initializer_list<base::AddressRegion> expected_regions) {
const auto& regions = mem.regions();
CHECK_EQ(regions.size(), expected_regions.size());
auto iter = expected_regions.begin();
for (auto it = regions.begin(), e = regions.end(); it != e; ++it, ++iter) {
CHECK_EQ(*it, *iter);
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
}
}
void DisjointAllocationPoolTest::CheckRange(base::AddressRegion region1,
base::AddressRegion region2) {
CHECK_EQ(region1, region2);
}
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 DisjointAllocationPoolTest::Make(
std::initializer_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
DisjointAllocationPool ret;
for (auto& region : regions) {
ret.Merge(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
}
return ret;
}
TEST_F(DisjointAllocationPoolTest, ConstructEmpty) {
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 a;
CHECK(a.IsEmpty());
CheckPool(a, {});
a.Merge({1, 4});
CheckPool(a, {{1, 4}});
}
TEST_F(DisjointAllocationPoolTest, ConstructWithRange) {
DisjointAllocationPool a({1, 4});
CHECK(!a.IsEmpty());
CheckPool(a, {{1, 4}});
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
}
TEST_F(DisjointAllocationPoolTest, SimpleExtract) {
DisjointAllocationPool a = Make({{1, 4}});
base::AddressRegion b = a.Allocate(2);
CheckPool(a, {{3, 2}});
CheckRange(b, {1, 2});
a.Merge(b);
CheckPool(a, {{1, 4}});
CHECK_EQ(a.regions().size(), 1);
CHECK_EQ(a.regions().front().begin(), 1);
CHECK_EQ(a.regions().front().end(), 5);
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
}
TEST_F(DisjointAllocationPoolTest, ExtractAll) {
DisjointAllocationPool a({1, 4});
base::AddressRegion b = a.Allocate(4);
CheckRange(b, {1, 4});
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
CHECK(a.IsEmpty());
a.Merge(b);
CheckPool(a, {{1, 4}});
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
}
TEST_F(DisjointAllocationPoolTest, FailToExtract) {
DisjointAllocationPool a = Make({{1, 4}});
base::AddressRegion b = a.Allocate(5);
CheckPool(a, {{1, 4}});
CHECK(b.is_empty());
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
}
TEST_F(DisjointAllocationPoolTest, FailToExtractExact) {
DisjointAllocationPool a = Make({{1, 4}, {10, 4}});
base::AddressRegion b = a.Allocate(5);
CheckPool(a, {{1, 4}, {10, 4}});
CHECK(b.is_empty());
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
}
TEST_F(DisjointAllocationPoolTest, ExtractExact) {
DisjointAllocationPool a = Make({{1, 4}, {10, 5}});
base::AddressRegion b = a.Allocate(5);
CheckPool(a, {{1, 4}});
CheckRange(b, {10, 5});
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
}
TEST_F(DisjointAllocationPoolTest, Merging) {
DisjointAllocationPool a = Make({{10, 5}, {20, 5}});
a.Merge({15, 5});
CheckPool(a, {{10, 15}});
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
}
TEST_F(DisjointAllocationPoolTest, MergingMore) {
DisjointAllocationPool a = Make({{10, 5}, {20, 5}, {30, 5}});
a.Merge({15, 5});
a.Merge({25, 5});
CheckPool(a, {{10, 25}});
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
}
TEST_F(DisjointAllocationPoolTest, MergingSkip) {
DisjointAllocationPool a = Make({{10, 5}, {20, 5}, {30, 5}});
a.Merge({25, 5});
CheckPool(a, {{10, 5}, {20, 15}});
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
}
TEST_F(DisjointAllocationPoolTest, MergingSkipLargerSrc) {
DisjointAllocationPool a = Make({{10, 5}, {20, 5}, {30, 5}});
a.Merge({25, 5});
a.Merge({35, 5});
CheckPool(a, {{10, 5}, {20, 20}});
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
}
TEST_F(DisjointAllocationPoolTest, MergingSkipLargerSrcWithGap) {
DisjointAllocationPool a = Make({{10, 5}, {20, 5}, {30, 5}});
a.Merge({25, 5});
a.Merge({36, 4});
CheckPool(a, {{10, 5}, {20, 15}, {36, 4}});
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
}
enum ModuleStyle : int { Fixed = 0, Growable = 1 };
std::string PrintWasmCodeManageTestParam(
::testing::TestParamInfo<ModuleStyle> info) {
switch (info.param) {
case Fixed:
return "Fixed";
case Growable:
return "Growable";
}
UNREACHABLE();
}
class WasmCodeManagerTest : public TestWithContext,
public ::testing::WithParamInterface<ModuleStyle> {
2017-11-20 21:34:04 +00:00
public:
2018-06-19 09:47:17 +00:00
static constexpr uint32_t kNumFunctions = 10;
static constexpr uint32_t kJumpTableSize = RoundUp<kCodeAlignment>(
JumpTableAssembler::SizeForNumberOfSlots(kNumFunctions));
2018-06-19 09:47:17 +00:00
using NativeModulePtr = std::shared_ptr<NativeModule>;
2017-11-20 21:34:04 +00:00
NativeModulePtr AllocModule(size_t size, ModuleStyle style) {
std::shared_ptr<WasmModule> module(new WasmModule);
module->num_declared_functions = kNumFunctions;
bool can_request_more = style == Growable;
return engine()->NewNativeModule(i_isolate(), kAllWasmFeatures, size,
can_request_more, std::move(module));
2017-11-20 21:34:04 +00:00
}
WasmCode* AddCode(NativeModule* native_module, uint32_t index, size_t size) {
CodeDesc desc;
memset(reinterpret_cast<void*>(&desc), 0, sizeof(CodeDesc));
std::unique_ptr<byte[]> exec_buff(new byte[size]);
desc.buffer = exec_buff.get();
desc.instr_size = static_cast<int>(size);
[wasm] Split adding code from publishing it This prepares a refactoring to add and publish compilation results in batches. For this, we need to separate the two phases, so that we can lock the module, allocate all the code space, release the lock, copy the code, lock the module, publish the code, and release the lock again. In particular, this CL does the following: 1) It removes the {AddOwnedCode} method. The functionality of creating the {WasmCode} and memcpy'ing the instruction into that is done in the other {Add*Code} methods. Adding to {owned_code_} is done in {PublishCode}. 2) {PublishInterpreterEntry} is now functionally equivalent to {PublishCode}, so it's removed. 3) After {AddCode}, the caller has to call {PublishCode}. In a follow-up CL, this will be called in batches (first {AddCode} them all, then {PublishCode} them all). 4) {AddCompiledCode} now assumes that the {WasmCompilationResult} succeeded. Otherwise, the caller should directly call {SetError} on the {CompilationState}. 5) {PublishCode} is now the chokepoint for installing code to the code table, the owned code vector, the jump table, and setting interpreter redirections. It replaces previous direct calls to {InstallCode} or explicitly adding to {owned_code_}. 6) Increasing the {generated_code_size_} counter is now done in {AllocateForCode}, which is the chokepoint for allocating space for generated code. This way, we will only increase this counter once once we allocate in batches. R=titzer@chromium.org Bug: v8:8916 Change-Id: I71e02e3a838f21797915cee3ebd373804fb12237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530817 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60369}
2019-03-20 13:04:33 +00:00
std::unique_ptr<WasmCode> code = native_module->AddCode(
index, desc, 0, 0, {}, {}, WasmCode::kFunction, WasmCode::kOther);
return native_module->PublishCode(std::move(code)).code;
2017-11-20 21:34:04 +00:00
}
size_t page() const { return AllocatePageSize(); }
WasmEngine* engine() { return i_isolate()->wasm_engine(); }
WasmCodeManager* manager() { return engine()->code_manager(); }
void SetMaxCommittedMemory(size_t limit) {
manager()->SetMaxCommittedMemoryForTesting(limit);
}
2017-11-20 21:34:04 +00:00
};
INSTANTIATE_TEST_SUITE_P(Parameterized, WasmCodeManagerTest,
::testing::Values(Fixed, Growable),
PrintWasmCodeManageTestParam);
TEST_P(WasmCodeManagerTest, EmptyCase) {
SetMaxCommittedMemory(0 * page());
CHECK_EQ(0, manager()->remaining_uncommitted_code_space());
ASSERT_DEATH_IF_SUPPORTED(AllocModule(1 * page(), GetParam()),
"OOM in NativeModule::AllocateForCode commit");
2017-11-20 21:34:04 +00:00
}
TEST_P(WasmCodeManagerTest, AllocateAndGoOverLimit) {
SetMaxCommittedMemory(1 * page());
CHECK_EQ(1 * page(), manager()->remaining_uncommitted_code_space());
NativeModulePtr native_module = AllocModule(1 * page(), GetParam());
CHECK(native_module);
CHECK_EQ(0, manager()->remaining_uncommitted_code_space());
uint32_t index = 0;
WasmCode* code = AddCode(native_module.get(), index++, 1 * kCodeAlignment);
CHECK_NOT_NULL(code);
CHECK_EQ(0, manager()->remaining_uncommitted_code_space());
code = AddCode(native_module.get(), index++, 3 * kCodeAlignment);
CHECK_NOT_NULL(code);
CHECK_EQ(0, manager()->remaining_uncommitted_code_space());
2018-06-19 09:47:17 +00:00
code = AddCode(native_module.get(), index++,
page() - 4 * kCodeAlignment - kJumpTableSize);
CHECK_NOT_NULL(code);
CHECK_EQ(0, manager()->remaining_uncommitted_code_space());
// This fails in "reservation" if we cannot extend the code space, or in
// "commit" it we can (since we hit the allocation limit in the
// WasmCodeManager). Hence don't check for that part of the OOM message.
ASSERT_DEATH_IF_SUPPORTED(
AddCode(native_module.get(), index++, 1 * kCodeAlignment),
"OOM in NativeModule::AllocateForCode");
2017-11-20 21:34:04 +00:00
}
TEST_P(WasmCodeManagerTest, TotalLimitIrrespectiveOfModuleCount) {
SetMaxCommittedMemory(3 * page());
NativeModulePtr nm1 = AllocModule(2 * page(), GetParam());
NativeModulePtr nm2 = AllocModule(2 * page(), GetParam());
CHECK(nm1);
CHECK(nm2);
2018-06-19 09:47:17 +00:00
WasmCode* code = AddCode(nm1.get(), 0, 2 * page() - kJumpTableSize);
CHECK_NOT_NULL(code);
2018-06-19 09:47:17 +00:00
ASSERT_DEATH_IF_SUPPORTED(AddCode(nm2.get(), 0, 2 * page() - kJumpTableSize),
"OOM in NativeModule::AllocateForCode commit");
2017-11-20 21:34:04 +00:00
}
TEST_P(WasmCodeManagerTest, GrowingVsFixedModule) {
SetMaxCommittedMemory(3 * page());
NativeModulePtr nm = AllocModule(1 * page(), GetParam());
size_t module_size = GetParam() == Fixed ? kMaxWasmCodeMemory : 1 * page();
size_t remaining_space_in_module = module_size - kJumpTableSize;
if (GetParam() == Fixed) {
// Requesting more than the remaining space fails because the module cannot
// grow.
ASSERT_DEATH_IF_SUPPORTED(
AddCode(nm.get(), 0, remaining_space_in_module + kCodeAlignment),
"OOM in NativeModule::AllocateForCode");
} else {
// The module grows by one page. One page remains uncommitted.
CHECK_NOT_NULL(
AddCode(nm.get(), 0, remaining_space_in_module + kCodeAlignment));
CHECK_EQ(manager()->remaining_uncommitted_code_space(), 1 * page());
2017-11-20 21:34:04 +00:00
}
}
TEST_P(WasmCodeManagerTest, CommitIncrements) {
SetMaxCommittedMemory(10 * page());
NativeModulePtr nm = AllocModule(3 * page(), GetParam());
WasmCode* code = AddCode(nm.get(), 0, kCodeAlignment);
CHECK_NOT_NULL(code);
CHECK_EQ(manager()->remaining_uncommitted_code_space(), 9 * page());
code = AddCode(nm.get(), 1, 2 * page());
CHECK_NOT_NULL(code);
CHECK_EQ(manager()->remaining_uncommitted_code_space(), 7 * page());
2018-06-19 09:47:17 +00:00
code = AddCode(nm.get(), 2, page() - kCodeAlignment - kJumpTableSize);
CHECK_NOT_NULL(code);
CHECK_EQ(manager()->remaining_uncommitted_code_space(), 7 * page());
2017-11-20 21:34:04 +00:00
}
TEST_P(WasmCodeManagerTest, Lookup) {
SetMaxCommittedMemory(2 * page());
NativeModulePtr nm1 = AllocModule(1 * page(), GetParam());
NativeModulePtr nm2 = AllocModule(1 * page(), GetParam());
WasmCode* code1_0 = AddCode(nm1.get(), 0, kCodeAlignment);
CHECK_EQ(nm1.get(), code1_0->native_module());
WasmCode* code1_1 = AddCode(nm1.get(), 1, kCodeAlignment);
WasmCode* code2_0 = AddCode(nm2.get(), 0, kCodeAlignment);
WasmCode* code2_1 = AddCode(nm2.get(), 1, kCodeAlignment);
CHECK_EQ(nm2.get(), code2_1->native_module());
CHECK_EQ(0, code1_0->index());
CHECK_EQ(1, code1_1->index());
CHECK_EQ(0, code2_0->index());
CHECK_EQ(1, code2_1->index());
// we know the manager object is allocated here, so we shouldn't
// find any WasmCode* associated with that ptr.
WasmCode* not_found =
manager()->LookupCode(reinterpret_cast<Address>(manager()));
CHECK_NULL(not_found);
WasmCode* found = manager()->LookupCode(code1_0->instruction_start());
CHECK_EQ(found, code1_0);
found = manager()->LookupCode(code2_1->instruction_start() +
(code2_1->instructions().size() / 2));
CHECK_EQ(found, code2_1);
found = manager()->LookupCode(code2_1->instruction_start() +
code2_1->instructions().size() - 1);
CHECK_EQ(found, code2_1);
found = manager()->LookupCode(code2_1->instruction_start() +
code2_1->instructions().size());
CHECK_NULL(found);
Address mid_code1_1 =
code1_1->instruction_start() + (code1_1->instructions().size() / 2);
CHECK_EQ(code1_1, manager()->LookupCode(mid_code1_1));
nm1.reset();
CHECK_NULL(manager()->LookupCode(mid_code1_1));
2017-11-20 21:34:04 +00:00
}
TEST_P(WasmCodeManagerTest, LookupWorksAfterRewrite) {
SetMaxCommittedMemory(2 * page());
NativeModulePtr nm1 = AllocModule(1 * page(), GetParam());
WasmCode* code0 = AddCode(nm1.get(), 0, kCodeAlignment);
WasmCode* code1 = AddCode(nm1.get(), 1, kCodeAlignment);
CHECK_EQ(0, code0->index());
CHECK_EQ(1, code1->index());
CHECK_EQ(code1, manager()->LookupCode(code1->instruction_start()));
WasmCode* code1_1 = AddCode(nm1.get(), 1, kCodeAlignment);
CHECK_EQ(1, code1_1->index());
CHECK_EQ(code1, manager()->LookupCode(code1->instruction_start()));
CHECK_EQ(code1_1, manager()->LookupCode(code1_1->instruction_start()));
2017-11-20 21:34:04 +00:00
}
} // namespace wasm_heap_unittest
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