1. 23 Jan, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Implement interpreter support for "throw". · 87773260
      Michael Starzinger authored
      This implements support for the "throw" operation in the interpreter.
      Note that support for catching/handling exceptions is still missing
      from the interpreter in will be done separately.
      
      This also introduces a {WasmExceptionPackage} class to the object model
      that acts as an interface for allocating and accessing exceptions that
      originate from WebAssembly. It does not represent a new instance type
      however as exceptions are instances of {WebAssembly.RuntimeError} for
      now.
      
      R=clemensh@chromium.org
      TEST=mjsunit/wasm/exceptions
      BUG=v8:8091
      
      Change-Id: I1f0cb548efb798e3c1488d42e4a31421c3c1aada
      Reviewed-on: https://chromium-review.googlesource.com/c/1430099Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59033}
      87773260
  2. 21 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      Reland "[wasm] Split compilation in three stages" · 6c2e35b9
      Clemens Hammacher authored
      This is a reland of 4e1d7c87.
      Failure on arm and arm64 is fixed by https://crrev.com/c/1411885.
      
      Original change's description:
      > [wasm] Split compilation in three stages
      >
      > In order to refactor ownership between objects in wasm compilation, the
      > compilation (executed by background tasks) is split in three stages:
      > getting a compilation unit (while holding a mutex), executing the work
      > (without any mutex and without keeping the NativeModule alive), and
      > submitting the work (with a mutex again).
      >
      > This CL prepares this design by splitting compilation from submission.
      > Both steps are still executed right after each other. This will be
      > changed in a follow-up CL.
      >
      > R=titzer@chromium.org
      > CC=mstarzinger@chromium.org
      >
      > Bug: v8:8689
      > Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
      > Reviewed-on: https://chromium-review.googlesource.com/c/1414920
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58929}
      
      TBR=titzer@chromium.org
      
      Bug: v8:8689
      Change-Id: I58ff07d0e0ac8df0f6ee23c416f992954f4673d2
      Reviewed-on: https://chromium-review.googlesource.com/c/1422748Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58959}
      6c2e35b9
  3. 18 Jan, 2019 2 commits
    • Michael Achenbach's avatar
      Revert "[wasm] Split compilation in three stages" · b7cc4f7a
      Michael Achenbach authored
      This reverts commit 4e1d7c87.
      
      Reason for revert:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/14986
      
      Original change's description:
      > [wasm] Split compilation in three stages
      > 
      > In order to refactor ownership between objects in wasm compilation, the
      > compilation (executed by background tasks) is split in three stages:
      > getting a compilation unit (while holding a mutex), executing the work
      > (without any mutex and without keeping the NativeModule alive), and
      > submitting the work (with a mutex again).
      > 
      > This CL prepares this design by splitting compilation from submission.
      > Both steps are still executed right after each other. This will be
      > changed in a follow-up CL.
      > 
      > R=​titzer@chromium.org
      > CC=​mstarzinger@chromium.org
      > 
      > Bug: v8:8689
      > Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
      > Reviewed-on: https://chromium-review.googlesource.com/c/1414920
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58929}
      
      TBR=titzer@chromium.org,clemensh@chromium.org
      
      Change-Id: Ic3d0287b354ef5f834b76bc2cdc096d2231f4477
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8689
      Reviewed-on: https://chromium-review.googlesource.com/c/1422917Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58932}
      b7cc4f7a
    • Clemens Hammacher's avatar
      [wasm] Split compilation in three stages · 4e1d7c87
      Clemens Hammacher authored
      In order to refactor ownership between objects in wasm compilation, the
      compilation (executed by background tasks) is split in three stages:
      getting a compilation unit (while holding a mutex), executing the work
      (without any mutex and without keeping the NativeModule alive), and
      submitting the work (with a mutex again).
      
      This CL prepares this design by splitting compilation from submission.
      Both steps are still executed right after each other. This will be
      changed in a follow-up CL.
      
      R=titzer@chromium.org
      CC=mstarzinger@chromium.org
      
      Bug: v8:8689
      Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
      Reviewed-on: https://chromium-review.googlesource.com/c/1414920Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58929}
      4e1d7c87
  4. 16 Jan, 2019 1 commit
  5. 15 Jan, 2019 2 commits
    • Andreas Haas's avatar
      [wasm][anyref] Support importing mutable anyref globals · b3e6013e
      Andreas Haas authored
      With this CL we support importing mutable anyref globals. The CL
      contains the following changes:
      
      * We store a reference to the buffer of the imported global in
        `WasmInstance::imported_mutable_globals_buffer`. This FixedArray is
        already used to keep the ArrayBuffers of value-typed imported
        mutable globals alive but was not accessed otherwise.
      
      * We store the offset in the buffer of the imported global in
        `WasmInstance::imported_mutable_globals`. This `Address`-array is
        used for value-typed imported mutalbe globals to store direct
        pointers into the backing store of the ArrayBuffer of the imported
        global.
      
      * In wasm-compiler.cc we generate code to load these fields and then
        load or store globals.
      
      * in module-compiler.cc I removed the counter variable
        `next_imported_mutable_global_index`. The variable was only used for
        a DCHECK. I replaced the DCHECK with a slightly weaker DCHECK now.
      
      * Tests.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:7581
      Change-Id: I11f0f4d8637c98eded5fb2eec44bc8ead8ed5c7b
      Reviewed-on: https://chromium-review.googlesource.com/c/1409169
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58822}
      b3e6013e
    • Ben L. Titzer's avatar
      [wasm] Implement table.drop · 97cdf35f
      Ben L. Titzer authored
      The table.drop bytecode "drops" the backing storage for an element
      initializer. In the V8 implementation, this is a nop, other than
      updating a per-instance boolean array so that two drops of the same
      segment or a drop of an active segment will trap.
      
      This is implemented with inline code in TurboFan in order to be symmetric
      to memory.drop, but could as easily be a runtime call to be supported in
      Liftoff.
      
      R=mstarzinger@chromium.org
      CC=​binji@chromium.org
      BUG=v8:7747
      
      Change-Id: Ic017398eaa764dd3a9ff19523453ff7142c9abf6
      Reviewed-on: https://chromium-review.googlesource.com/c/1408996Reviewed-by: 's avatarBen Smith <binji@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58817}
      97cdf35f
  6. 14 Jan, 2019 2 commits
  7. 10 Jan, 2019 2 commits
  8. 12 Dec, 2018 1 commit
    • Ben Smith's avatar
      [wasm] Implement memory.init and memory.drop · 4084185b
      Ben Smith authored
      `memory.init` copies bytes from a passive data segment to linear memory.
      
      `memory.drop` is an instruction that informs the wasm VM that the instance no
      longer needs access to the passive data segment.
      
      Information about the passive data segments, including their contents, length,
      and whether they are dropped, is stored in the `WasmInstanceObject` as primitive
      arrays.
      
      Bug: v8:7747
      Change-Id: I1515c8868c9be227743456a539126c15280b5365
      Reviewed-on: https://chromium-review.googlesource.com/c/1370691Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Ben Smith <binji@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58196}
      4084185b
  9. 11 Dec, 2018 1 commit
  10. 10 Dec, 2018 2 commits
  11. 26 Nov, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Intrinsify math imports · 99484e23
      Ben L. Titzer authored
      This CL adds new Wasm import call kinds that correspond to various
      math functions that can be imported from JavaScript, such as trigonometry.
      Instead of calling a special import wrapper that converts arguments
      to tagged values by boxing, we can now generate calls to little WASM
      stubs that contain a single WASM bytecode each.
      
      R=mstarzinger@chromium.org
      BUG=v8:8423
      
      Change-Id: I59b1be2dd36d190a8b6c98b88c86cecc0ca7f4a2
      Reviewed-on: https://chromium-review.googlesource.com/c/1349279
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57835}
      99484e23
  12. 13 Nov, 2018 1 commit
  13. 07 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Decouple wire bytes from compilation units · 014d9e4f
      Clemens Hammacher authored
      Compilation units currently contain pointers into allocated space that
      contains the code of the respective function. This requires us to keep
      the StreamingDecoder alive as long as compilation is still running
      (including tiering).
      This CL refactors this by having an additional redirection
      (WireBytesStorage) which can point to either the StreamingDecoder or
      the NativeModule. We only keep the code section buffer alive as long as
      the StreamingWireBytesStorage is still in use.
      
      I will further refactor memory ownership in a follow-up CL to not make
      the AsyncCompileJob keep the StreamingDecoder alive.
      
      R=ahaas@chromium.org
      
      Bug: v8:8343,v8:7921,v8:8050
      Change-Id: I780582c3217abf64000454f2c9c108b9ac9fbff1
      Reviewed-on: https://chromium-review.googlesource.com/c/1319588Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57317}
      014d9e4f
  14. 30 Oct, 2018 2 commits
  15. 29 Oct, 2018 5 commits
  16. 25 Oct, 2018 1 commit
  17. 23 Oct, 2018 3 commits
  18. 22 Oct, 2018 1 commit
  19. 19 Oct, 2018 2 commits
  20. 10 Oct, 2018 2 commits
    • Ben L. Titzer's avatar
      [wasm] Cache import wrappers in NativeModule · 98e3e32d
      Ben L. Titzer authored
      Now that import wrappers are no longer specialized to an index, they
      can be cached in the native module, keyed by
      (WasmImportCallKind, FunctionSig). This saves instantiation time and
      also fixes a (slow) memory leak.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I5197bbfae79d6e811a01289b990db445373eea6c
      Reviewed-on: https://chromium-review.googlesource.com/c/1270943
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56526}
      98e3e32d
    • Ben L. Titzer's avatar
      [wasm] Use a tuple as the instance for JS imports · a2b34806
      Ben L. Titzer authored
      This CL refactors the implementation of WASM->JS import wrappers in order
      to make the wrapper code shareable. Instead of specializing to the import
      index, we use a tuple as the object ref in the both the import and indirect
      tables. The tuple allows the wrapper code to load both the calling
      instance and the target callable, rather than relying on code specialization.
      
      This requires some tricky codegen machinery, because WASM call descriptors
      expect an instance argument in a given register, yet the wrappers receive
      a tuple, the code generator must generate a prologue that loads the
      instance (and the callable), since it is not possible to express this at
      the graph level.
      
      R=mstarzinger@chromium.org
      CC=clemensh@chromium.org
      
      Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6
      Reviewed-on: https://chromium-review.googlesource.com/c/1268237
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56520}
      a2b34806
  21. 25 Sep, 2018 2 commits
    • Ben L. Titzer's avatar
      [wasm] Load formal_param_count for mismatched import calls · 89f52f8a
      Ben L. Titzer authored
      For WASM import calls to JSFunctions where the arity is mismatched,
      we currently generate code that inlines the formal parameter count
      of the target function as a constant in a call to the arguments
      adapter. This CL changes this to generate code that loads the formal
      parameter count from the function at runtime in order to permit
      more sharing later.
      
      R=mstarzinger@chromium.org
      CC=clemensh@chromium.org
      
      Change-Id: I5cce97fc338f6468f9d42d48f5bc860b25fb7d73
      Reviewed-on: https://chromium-review.googlesource.com/1243108
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56220}
      89f52f8a
    • Ben L. Titzer's avatar
      [wasm] Introduce WasmImportCallKind enum · 7f7545cf
      Ben L. Titzer authored
      The WASM engine compiles per-import wrappers for callables imported
      into a WASM instance that have one of a number of different shapes,
      depending on the type of the imported function and whether there is
      a signature match. This CL introduces an enum with a value for each
      case in preparation for introducing a per-kind cache.
      
      R=mstarzinger@chromium.org
      CC=clemensh@chromium.org
      
      Change-Id: If9b7355ff7c57a329c096f93f3624bc3d6c74e3f
      Reviewed-on: https://chromium-review.googlesource.com/1243045
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56210}
      7f7545cf
  22. 24 Sep, 2018 1 commit
  23. 17 Sep, 2018 3 commits