Skip to content

V
V8
Switch branch/tag
  1. 16 Sep, 2017 2 commits
    • Mircea Trofin's avatar
      Revert "[wasm] A simple allocator datastructure for off-the heap" · ee5c31f3
      Mircea Trofin authored 
      This reverts commit 110d9ab0.

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/670141Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48054}
      ee5c31f3
    • Mircea Trofin's avatar
      [wasm] A simple allocator datastructure for off-the heap · 110d9ab0
      Mircea Trofin authored 
      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: 's avatarEric Holk <eholk@chromium.org>
Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48053}
      110d9ab0
  3. 15 Sep, 2017 32 commits
  5. 14 Sep, 2017 6 commits