1. 11 Apr, 2019 1 commit
  2. 09 Apr, 2019 4 commits
  3. 08 Apr, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Support reference types on interpreter entry. · 0bed5887
      Michael Starzinger authored
      This adds preliminary support for references types as argument or return
      values to functions that are redirected to the interpreter. The current
      interpreter entry stub remains unchanged, using one buffer area that is
      hidden from the GC. The corresponding {Runtime_WasmRunInterpreter} now
      correctly boxes/un-boxes reference types into handles. This switch to a
      handlified representation happens before any method that potentially
      triggers a GC is called.
      
      R=clemensh@chromium.org
      TEST=mjsunit/wasm/exceptions-anyref-interpreter
      BUG=v8:8091,v8:7581
      
      Change-Id: I41c766ed5ac877042d5964e72f3fd7df390c4e98
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557147
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60684}
      0bed5887
  4. 05 Apr, 2019 4 commits
  5. 03 Apr, 2019 1 commit
  6. 29 Mar, 2019 1 commit
  7. 28 Mar, 2019 1 commit
  8. 26 Mar, 2019 2 commits
  9. 25 Mar, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Handle rejected input promise in WebAssembly.compileStreaming · 8cbcae37
      Andreas Haas authored
      In the implementation of WebAssembly.compileStreaming and
      WebAssembly.instantiateStreaming, we did not handle the case where the
      input, which is a Promise, gets rejected. When this Promise got
      rejected, the Promise returned by compileStreaming remained pending
      forever.
      
      With this CL, the rejection object of the input Promise gets forwarded
      to the result Promise.
      
      I also extended the --wasm-test-streaming flag to provide
      WebAssembly.compileStreaming and WebAssembly.instantiateStreaming
      in d8. The difference to the Chrome versions of these function is
      that d8 does not know about Response objects. That's why in d8
      compileStreaming and instantiateStreaming expect a Promise to an
      ArrayBuffer or a TypedArray and not to a Response object.
      
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Bug: chromium:943487
      Change-Id: I77f789e9ae5d50ae9c9bc92bf27dbfe338fe0f13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535817Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60427}
      8cbcae37
  10. 21 Mar, 2019 2 commits
  11. 20 Mar, 2019 2 commits
  12. 19 Mar, 2019 3 commits
  13. 18 Mar, 2019 4 commits
  14. 15 Mar, 2019 4 commits
  15. 14 Mar, 2019 2 commits
  16. 13 Mar, 2019 3 commits
  17. 12 Mar, 2019 2 commits
    • Clemens Hammacher's avatar
      [wasm] Sync wasm-module-builder.js back to spec version · 1a81a392
      Clemens Hammacher authored
      In particular, remove {toUint8Array} method and make {toBuffer} return
      a {Uint8Array} view to the buffer like before
      https://crrev.com/c/1508352. Also, the returned view does not need to be
      another copy of the bytes, it can really just be a view.
      
      As a follow-up, this requires the test-only DeserializeWasmModule
      runtime method to receive the wire bytes as Uint8Array, and also
      requires the {IsWasmCompileAllowed} callback to handle
      {ArrayBufferView} (like chromium's version already does).
      
      R=ahaas@chromium.org
      
      Change-Id: I87296cdbac14b74e7c8b38a372aa3df572ca6ad6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518172
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60195}
      1a81a392
    • Andreas Haas's avatar
      [wasm] Fix insufficient bounds check in WebAssembly.get · e162eb44
      Andreas Haas authored
      According to the wasm js-spec, the table index can be uint32. The
      implementation in our implementation expected an int though. We did not
      check for the int overflow.
      
      I replaced the throwing of the exception in WasmTableObject::Get to use
      the ErrorThrower instead of throwing the exception with Isolate::Throw
      directly. The reason is that I see with other CL's that I have to throw
      several errors, and I don't want to introduce a new message and
      MessageId for every error. Moreover, the ErrorThrower is a standard way
      in wasm to throw errors. It feels right to throw the error the same way
      here.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:940296
      Change-Id: Idb77c813506fe66a3192b66fe0e8e807b80580ab
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514496
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60181}
      e162eb44
  18. 11 Mar, 2019 1 commit
  19. 09 Mar, 2019 1 commit