1. 18 Sep, 2017 10 commits
  2. 17 Sep, 2017 1 commit
  3. 16 Sep, 2017 4 commits
    • peterwmwong's avatar
      [builtins] Convert String HTML functions (ex. anchor, big, bold) to CSA · 8dfdeae0
      peterwmwong authored
        - Added TFJ builtins for S.p.{anchor, big, blink, bold, fontcolor,
            fontsize, fixed, italics, link, small, strike, sub, sup}
        - Removed functionality from string.js
      
      Bug: v8:5049
      Change-Id: I3a91b52eaceef5c47bb55ed62780d72ef1e802e9
      Reviewed-on: https://chromium-review.googlesource.com/666487
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48056}
      8dfdeae0
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" · 3d046986
      Mircea Trofin authored
      This reverts commit ee5c31f3.
      
      Reason for revert: Fixed compiler failure
      
      Original change's description:
      > Revert "[wasm] A simple allocator datastructure for off-the heap"
      > 
      > 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/670141
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48054}
      
      TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/670142
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48055}
      3d046986
    • 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
  4. 15 Sep, 2017 25 commits