110d9ab005
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} |
||
|---|---|---|
| .. | ||
| benchmarks | ||
| cctest | ||
| common | ||
| debugger | ||
| fuzzer | ||
| inspector | ||
| intl | ||
| js-perf-test | ||
| memory | ||
| message | ||
| mjsunit | ||
| mkgrokdump | ||
| mozilla | ||
| preparser | ||
| promises-aplus | ||
| test262 | ||
| unittests | ||
| wasm-spec-tests | ||
| webkit | ||
| bot_default.gyp | ||
| bot_default.isolate | ||
| BUILD.gn | ||
| default.gyp | ||
| default.isolate | ||
| optimize_for_size.gyp | ||
| optimize_for_size.isolate | ||
| perf.gyp | ||
| perf.isolate | ||