1. 30 Jan, 2019 1 commit
  2. 25 Oct, 2017 1 commit
  3. 16 Oct, 2017 1 commit
  4. 06 Jun, 2017 1 commit
  5. 18 May, 2017 1 commit
    • Mircea Trofin's avatar
      [wasm] {compile|instantiate}Streaming · 47702c53
      Mircea Trofin authored
      As per spec, (https://github.com/WebAssembly/design/pull/1068), we
      don't have compile/instantiate overloads anymore, instead, we
      have explicitly named members.
      
      This change introduces the new APIs, implements instantiateStreaming
      based on compileStreaming, and uses the existing embedder mechanism.
      It does not yet remove the functionality from compile/instantiate -
      we do that after we adopt the new APIs on the blink side.
      
      Also, it temporarily handles exceptions on the v8 side, which is also
      something we'll move to the blink side.
      
      Bug: 
      Change-Id: I77673b1c0d395dfcf13b2f25464fd5dfd99c8d82
      Reviewed-on: https://chromium-review.googlesource.com/508852
      Commit-Queue: Brad Nelson <bradnelson@chromium.org>
      Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45411}
      47702c53
  6. 10 May, 2017 3 commits
  7. 09 May, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "Revert "Revert "Introducing an event loop mechanism for d8.""" · 02595c60
      Michael Achenbach authored
      This reverts commit 7dcc8eff.
      
      Reason for revert: Some flakes still (see comments) and breaks predictable testing:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20predictable/builds/11452
      
      Original change's description:
      > Revert "Revert "Introducing an event loop mechanism for d8.""
      > 
      > This reverts commit f7c25da6.
      > 
      > Reason for revert: Fixed
      > 
      > Original change's description:
      > > Revert "Introducing an event loop mechanism for d8."
      > > 
      > > This reverts commit de964dbe.
      > > 
      > > Reason for revert:
      > > https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/17958
      > > 
      > > Original change's description:
      > > > Introducing an event loop mechanism for d8.
      > > > 
      > > > This mechanism ensures APIs like wasm async complete their work, 
      > > > without requiring use of natives (%APIs).
      > > > 
      > > > The mechanism is similar to the one used in content_shell,
      > > > which should allow us to easily port tests in that environment.
      > > > 
      > > > Review-Url: https://codereview.chromium.org/2842843005
      > > > Cr-Original-Commit-Position: refs/heads/master@{#44908}
      > > > Bug: 
      > > > Change-Id: I9deee0d256a600c60b42902fc8ef8478e5546344
      > > > Reviewed-on: https://chromium-review.googlesource.com/494968
      > > > Commit-Queue: Mircea Trofin <mtrofin@google.com>
      > > > Reviewed-by: Jochen Eisinger <jochen@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#45165}
      > > 
      > > TBR=bradnelson@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org
      > > NOPRESUBMIT=true
      > > NOTREECHECKS=true
      > > NOTRY=true
      > > 
      > > Change-Id: Iafec2615d705d1990c57229cab3a988c00b5e12f
      > > Reviewed-on: https://chromium-review.googlesource.com/498630
      > > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#45166}
      > 
      > TBR=bradnelson@chromium.org,machenbach@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org,v8-reviews@googlegroups.com
      > NOPRESUBMIT=true
      > NOTREECHECKS=true
      > NOTRY=true
      > 
      > Change-Id: Ic3c782e918326e291a6cb9bb349c609e9a340b09
      > Reviewed-on: https://chromium-review.googlesource.com/498430
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Commit-Queue: Mircea Trofin <mtrofin@google.com>
      > Cr-Commit-Position: refs/heads/master@{#45172}
      
      TBR=bradnelson@chromium.org,machenbach@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org,v8-reviews@googlegroups.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Change-Id: I21ffba7141db0bfb4a3275b6e1bf4fb399800ed2
      Reviewed-on: https://chromium-review.googlesource.com/500128Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45177}
      02595c60
  8. 08 May, 2017 3 commits
  9. 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
  10. 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