Skip to content

V
V8
Switch branch/tag
  1. 19 Sep, 2017 2 commits
    • Mircea Trofin's avatar
      [wasm] Sanitize imports · 1bc42ab4
      Mircea Trofin authored 
      Sanitize imports before we start the instance building process. This
avoids the possibility of exiting to JS while building instances,
and allowing JS to observe an inconsistent state of the wasm world -
e.g. incomplete specialization chains.

We now validate we never exit to JS during that process.

Bug: chromium:766260

Change-Id: I34930c8b70bdac16af464b3f62a2b6a38107acb3
Reviewed-on: https://chromium-review.googlesource.com/671480
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48074}
      1bc42ab4
    • Eric Holk's avatar
      [d8] zero realm_count_ on RealmScope teardown · e6defddc
      Eric Holk authored 
      Promises can sometimes be resolved after the RealmScope has been destroyed, such
as when a Wasm compile job finishes after the script main has finished. If the
Promise.then function refers to Realm.current, we were getting a use-after free
error when it would search for the list of realms. This change also zeros out
realm_count_ in addition to deleting the realms_ so that RealmFind will not
reference freed memory.

Bug: chromium:761710
Change-Id: I2d42997f363b284ccc5f4b225d3f59e0361e68d6
Reviewed-on: https://chromium-review.googlesource.com/671923Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48073}
      e6defddc
  3. 18 Sep, 2017 15 commits
  5. 17 Sep, 2017 1 commit
  7. 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
  9. 15 Sep, 2017 18 commits