Skip to content

V
V8
Switch branch/tag
  1. 03 Aug, 2017 2 commits
  3. 02 Aug, 2017 1 commit
  5. 02 Jun, 2017 1 commit
  7. 18 Apr, 2017 1 commit
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 71cf4890
      mtrofin authored 
      Today, the semantics of:

WebAssembly.instantiate

and

WebAssembly.compile().then(new WebAssemblyInstance)

are subtly different, to the point where attempting the proposed
change uncovered bugs.

In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.

This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.

- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.

BUG=chromium:697028

Review-Url: https://codereview.chromium.org/2806073002
Cr-Original-Commit-Position: refs/heads/master@{#44592}
Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb
Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44669}
      71cf4890
  9. 12 Apr, 2017 2 commits
    • hablich's avatar
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6... · d3f1d5c5
      hablich authored 
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ )

Reason for revert:
Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824

Original issue's description:
> [wasm] instantiate expressed in terms of compile
>
> Today, the semantics of:
>
> WebAssembly.instantiate
>
> and
>
> WebAssembly.compile().then(new WebAssemblyInstance)
>
> are subtly different, to the point where attempting the proposed
> change uncovered bugs.
>
> In the future, it's possible that .instantiate actually have different
> semantics - if we pre-specialized to the provided ffi, for example.
> Right now that's not the case.
>
> This CL:
> - gets our implementation closer to what developers may write using
> the compile -> new Instance alternative, in particular wrt promise
> creation. By reusing code paths, we uncover more bugs, and keep
> maintenance cost lower.
>
> - it gives us the response-based WebAssembly.instantiate implicitly.
> Otherwise, we'd need that same implementation on the blink side. The
> negative is maintenance: imagine if the bugs I mentioned could only be
> found when running in Blink.
>
> BUG=chromium:697028
>
> Review-Url: https://codereview.chromium.org/2806073002
> Cr-Commit-Position: refs/heads/master@{#44592}
> Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb

TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:697028

Review-Url: https://codereview.chromium.org/2810203002
Cr-Commit-Position: refs/heads/master@{#44614}
      d3f1d5c5
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 7829af32
      mtrofin authored 
      Today, the semantics of:

WebAssembly.instantiate

and

WebAssembly.compile().then(new WebAssemblyInstance)

are subtly different, to the point where attempting the proposed
change uncovered bugs.

In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.

This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.

- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.

BUG=chromium:697028

Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44592}
      7829af32
  11. 11 Apr, 2017 1 commit
  13. 06 Apr, 2017 1 commit
  15. 03 Apr, 2017 2 commits
  17. 26 Jan, 2017 1 commit
    • gdeepti's avatar
      [wasm] Memory buffer should be detached after Memory.Grow · e6d13999
      gdeepti authored 
      Memory.Grow should detach the ArrayBuffer associated with the Mem object after Grow. Currently, when guard pages are enabled protection is changed to make more of the buffer accessible. This does not work for when the buffer should be detached after grow, because the memory object has a reference to the same buffer befor/after grow.

R=titzer@chromium.org, eholk@chromium.org

Review-Url: https://codereview.chromium.org/2653183003
Cr-Commit-Position: refs/heads/master@{#42717}
      e6d13999
  19. 25 Jan, 2017 1 commit
  21. 24 Jan, 2017 2 commits
  23. 20 Jan, 2017 2 commits
  25. 18 Jan, 2017 1 commit
  27. 16 Jan, 2017 2 commits
  29. 15 Jan, 2017 1 commit
  31. 13 Jan, 2017 1 commit
  33. 12 Jan, 2017 3 commits
  35. 11 Jan, 2017 3 commits
  37. 10 Jan, 2017 1 commit
  39. 21 Dec, 2016 1 commit
  41. 20 Dec, 2016 1 commit
  43. 19 Dec, 2016 1 commit