[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}
Showing
src/wasm/wasm-heap.cc
0 → 100644
src/wasm/wasm-heap.h
0 → 100644
Please
register
or
sign in
to comment