-
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: Mircea Trofin <mtrofin@chromium.org> Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48054}
ee5c31f3