Skip to content

V
V8
Switch branch/tag
  1. 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
  3. 15 Sep, 2017 32 commits
  5. 14 Sep, 2017 4 commits