1. 16 Sep, 2017 1 commit
    • 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
  2. 15 Sep, 2017 32 commits
  3. 14 Sep, 2017 7 commits