1. 16 Feb, 2021 1 commit
  2. 11 Feb, 2021 1 commit
    • Thibaud Michaud's avatar
      [wasm][interpreter][eh] Implement catch with immediate · 44054826
      Thibaud Michaud authored
      In the latest spec, catch can take an exception index immediate, and
      control-flow jumps to the appropriate catch handler depending on the
      thrown exception.
      
      Do this by allowing multiple jump targets for the same pc in labels and
      in the control transfer map. At runtime, the unwinder will choose the
      appropriate control transfer entry based on the exception tag, unpack
      the exception and jump to the handler.
      
      Enable the exception cctests that were currently disabled for the
      interpreter, fix some issues and add tests for the new behaviors.
      
      R=clemensb@chromium.org
      
      Bug: v8:8091
      Change-Id: I30cb8f9459647a7c6f7bfd9785b238a9c9e9fc10
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690587Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72661}
      44054826
  3. 06 Nov, 2020 1 commit
  4. 10 Aug, 2020 1 commit
  5. 25 Jun, 2020 1 commit
  6. 23 Jun, 2020 1 commit
  7. 05 Jun, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][interpreter] Remove threads support · 47e501e1
      Clemens Backes authored
      The wasm interpreter was always single-threaded, and there are no plans
      to change this. Still, there was a concept of threads, but with the
      hard-coded constraint that there is always exactly one of them.
      
      In order to clean up the code, and as a preparation to remove more
      unneeded functionality before moving the interpreter over to the test
      directory, this CL removes the concept of threads and merges the
      {ThreadImpl} class into {WasmInterpreterInternals}.
      
      Drive-by: Remove the dead {GetFrameCount} method.
      
      R=ahaas@chromium.org
      
      Bug: v8:10389
      Change-Id: If65cdd21b34ce8debf8ba0f24dbeacec15e0a1d7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2231354Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68204}
      47e501e1
  8. 02 Jun, 2020 2 commits
  9. 26 May, 2020 1 commit
  10. 25 May, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][interpreter] Remove breakpoint support · 843a1f45
      Clemens Backes authored
      The interpreter is not used for debugging any more. Hence any breakpoint
      support and related functionality is dead code.
      
      This CL removes
      - the {SetBreakpoint} and {GetBreakpoint} methods,
      - the {break_pc_} field which holds the current pause position,
      - the {break_flags_} field which is used to break at function entry and
        after calls,
      - functions to modify {break_flags_},
      - the dead {kInternalBreakpoint} and {kInvalidPc} constants (plus
        respective macros and enums),
      - the {orig_start} and {orig_end} fields (code is not being modified any
        more, so we just use {start} and {end} now),
      - the {PrepareStepIn} method,
      - the unimplemented {SetTracing} method, and
      - two tests that test breakpoints in the interpreter.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10389
      Change-Id: I52103c37516446e40d3dfa365d6b480a7c623577
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215163
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67958}
      843a1f45
  11. 18 Nov, 2019 1 commit
  12. 24 Oct, 2019 1 commit
  13. 21 Oct, 2019 1 commit
  14. 16 Oct, 2019 1 commit
  15. 26 Sep, 2019 1 commit
  16. 17 Sep, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Make WasmInterpreterInternals a normal object · e92e8871
      Andreas Haas authored
      For unknown reasons, WasmInterpreterInternals was a zone object. However
      WasmInterpreterInternals indirectly owns a global handle and a
      unique_ptr, both for the interpreter stack. As a zone object,
      WasmInterpreterInternals is never destructed, and therefore never frees
      the unique_ptr. With this CL I make WasmInterpreterInternals a normal
      object and allocate it into a unique_ptr, so that it gets destructed
      properly.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:1000610
      Change-Id: Ie08c5627393a434521f5c32702bf9945db2c7811
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807361Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63835}
      e92e8871
  17. 13 Sep, 2019 1 commit
  18. 10 May, 2019 1 commit
  19. 27 Mar, 2019 1 commit
  20. 21 Mar, 2019 1 commit
    • Ben Smith's avatar
      [wasm] Call through dispatch table in interpreter · 1a88414c
      Ben Smith authored
      When running wasm tests, the interpreter previously used a static
      collection of function indexes stored in WasmTable to perform
      call_indirect calls internal to that module. This has the wrong behavior
      if the table is changed (via WasmTableObject::Set, `table.copy`, or
      `table.init`).
      
      This CL changes the cctests to always generate an intepreter entry for
      all functions, and stores those entries in the dispatch table. This
      allows us to use the same execution path as for non-testing code.
      
      The interpreter entry compiler needed to be changed to support
      multi-value returns too, since a 64-bit integer return value may be
      lowered to two 32-bit integer returns.
      
      Bug: v8:9016
      Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60380}
      1a88414c
  21. 12 Mar, 2019 1 commit
  22. 07 Feb, 2019 1 commit
  23. 03 Oct, 2018 1 commit
    • Hans Wennborg's avatar
      Fix -Wdefaulted-function-deleted warnings · cb8d93e1
      Hans Wennborg authored
      This is part of clean-up for a new Clang warning that we'd like to
      enable. This patch addresses all warnings from V8 that I saw in a full debug
      build of Chromium on Linux.
      
      ../../v8/src/reloc-info.h:405:18: warning: explicitly defaulted move assignment
      operator is implicitly deleted [-Wdefaulted-function-deleted]
        RelocIterator& operator=(RelocIterator&&) = default;
                       ^
      ../../v8/src/reloc-info.h:447:13: note: move assignment operator of
      'RelocIterator' is implicitly deleted because field 'mode_mask_' is of
      const-qualified type 'const int'
        const int mode_mask_;
                  ^
      
      ../../v8/src/wasm/baseline/liftoff-compiler.cc:111:36: warning: explicitly
      defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted]
        MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(LiftoffCompiler);
                                         ^
      ../../v8/src/wasm/baseline/liftoff-compiler.cc:1834:20: note: move constructor
      of 'LiftoffCompiler' is implicitly deleted because field 'asm_' has a deleted
      move constructor
        LiftoffAssembler asm_;
                         ^
      
      ../../v8/src/wasm/wasm-debug.cc:95:3: warning: explicitly defaulted move
      assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
        MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(InterpreterHandle);
        ^
      ../../v8/src/wasm/wasm-debug.cc:98:19: note: move assignment operator of
      'InterpreterHandle' is implicitly deleted because field 'interpreter_' has a
      deleted move assignment operator
        WasmInterpreter interpreter_;
                        ^
      ../../v8/src/wasm/wasm-interpreter.h:211:35: note: copy assignment operator of
      'WasmInterpreter' is implicitly deleted because field 'internals_' is of
      const-qualified type 'v8::internal::wasm::WasmInterpreterInternals *const'
        WasmInterpreterInternals* const internals_;
                                        ^
      
      Bug: chromium:890307
      Change-Id: Idfc5827f24821212081a006c4329c466c4576bcc
      Reviewed-on: https://chromium-review.googlesource.com/c/1256863
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56351}
      cb8d93e1
  24. 05 Jul, 2018 1 commit
  25. 02 May, 2018 1 commit
  26. 06 Apr, 2018 1 commit
  27. 04 Apr, 2018 2 commits
    • Ben Titzer's avatar
      Revert "[wasm] Merge the WasmContext into WasmInstanceObject" · 8adb94fc
      Ben Titzer authored
      This reverts commit 57bf0bfe.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] Merge the WasmContext into WasmInstanceObject
      > 
      > This change makes lifetime management of WasmCode much simpler.
      > By using the WasmInstanceObject as the context for WASM code execution,
      > including the pointer to the memory base and indirect function tables,
      > this keeps the instance alive when WASM code is on the stack, since
      > the instance object is passed as a parameter and spilled onto the stack.
      > This is in preparation of sharing the code between instances and
      > isolates.
      > 
      > Bug: v8:7424
      > 
      > Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      > Reviewed-on: https://chromium-review.googlesource.com/958520
      > Commit-Queue: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52361}
      
      TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7424
      Reviewed-on: https://chromium-review.googlesource.com/995418Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52364}
      8adb94fc
    • Ben L. Titzer's avatar
      [wasm] Merge the WasmContext into WasmInstanceObject · 57bf0bfe
      Ben L. Titzer authored
      This change makes lifetime management of WasmCode much simpler.
      By using the WasmInstanceObject as the context for WASM code execution,
      including the pointer to the memory base and indirect function tables,
      this keeps the instance alive when WASM code is on the stack, since
      the instance object is passed as a parameter and spilled onto the stack.
      This is in preparation of sharing the code between instances and
      isolates.
      
      Bug: v8:7424
      
      Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      Reviewed-on: https://chromium-review.googlesource.com/958520
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52361}
      57bf0bfe
  28. 21 Feb, 2018 1 commit
  29. 02 Feb, 2018 1 commit
  30. 20 Dec, 2017 1 commit
  31. 16 Oct, 2017 1 commit
  32. 07 Aug, 2017 1 commit
    • Mircea Trofin's avatar
      [wasm] Clarify source of runtime information for interpreter. · 3f1e32b3
      Mircea Trofin authored
      This is part of the effort to consolidate the ownership of
      wasm instantiation/specialization parameters.
      
      This change is focused solely on the interpreter part of that effort, to
      verify we're not regressing performance in interpreter benchmarks.
      
      There are two aspects being addressed:
      - dataflow-wise, we always fetch the interpreter's memory view from the
      runtime objects (i.e. WasmInstanceObject/WasmCompiledModule). This is
      consistent with how other instance-specific information is obtained
      (e.g. code, indirect functions).
      
      - representation-wise, we do not reuse ModuleEnv/WasmInstance just for
      the memory view, because it is surprising that other instance info isn't
      accessed from there. 
      
      Bug: 
      Change-Id: I536fbffd8e1f142a315fa1770ba9b08319f56a8e
      Reviewed-on: https://chromium-review.googlesource.com/602083Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47205}
      3f1e32b3
  33. 18 Jul, 2017 1 commit
  34. 14 Jul, 2017 1 commit
    • Clemens Hammacher's avatar
      Reland "[wasm] Don't store global handles in the interpreter" · b53141ec
      Clemens Hammacher authored
      This is a reland of 5648aad5.
      Previous compile error should be fixed by disabling strict aliasing
      assumptions on gyp: https://chromium-review.googlesource.com/c/571806
      
      Original change's description:
      > [wasm] Don't store global handles in the interpreter
      > 
      > Storing global handles in the interpreter is dangerous, because the
      > global handles are strong roots into the heap. The interpreter itself is
      > referenced from the heap via a Managed. Hence the interpreter keeps the
      > instance alive, while the instance keeps the Managed alive. So the GC
      > will never collect them.
      > 
      > This CL refactors this to only store the handle to the instance object
      > while executing in the interpreter, and clearing it when returning.
      > It also removes the cache of import wrappers, as it should not be
      > performance critical, but keeps lots of objects alive. If it turns out
      > to be performance critical, we will have to reintroduce such a cache
      > stored in the WasmDebugInfo object.
      > 
      > R=titzer@chromium.org
      > CC=ahaas@chromium.org
      > 
      > Bug: chromium:610330
      > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      > Reviewed-on: https://chromium-review.googlesource.com/567058
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46629}
      
      TBR=titzer@chromium.org
      
      Bug: chromium:610330
      Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b
      Reviewed-on: https://chromium-review.googlesource.com/570578
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46679}
      b53141ec
  35. 13 Jul, 2017 2 commits
    • Clemens Hammacher's avatar
      Revert "[wasm] Don't store global handles in the interpreter" · 199a26f7
      Clemens Hammacher authored
      This reverts commit 5648aad5.
      
      Reason for revert: Compile error on mips:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732
      
      Original change's description:
      > [wasm] Don't store global handles in the interpreter
      > 
      > Storing global handles in the interpreter is dangerous, because the
      > global handles are strong roots into the heap. The interpreter itself is
      > referenced from the heap via a Managed. Hence the interpreter keeps the
      > instance alive, while the instance keeps the Managed alive. So the GC
      > will never collect them.
      > 
      > This CL refactors this to only store the handle to the instance object
      > while executing in the interpreter, and clearing it when returning.
      > It also removes the cache of import wrappers, as it should not be
      > performance critical, but keeps lots of objects alive. If it turns out
      > to be performance critical, we will have to reintroduce such a cache
      > stored in the WasmDebugInfo object.
      > 
      > R=​titzer@chromium.org
      > CC=ahaas@chromium.org
      > 
      > Bug: chromium:610330
      > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      > Reviewed-on: https://chromium-review.googlesource.com/567058
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46629}
      
      TBR=titzer@chromium.org,clemensh@chromium.org
      
      Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:610330
      Reviewed-on: https://chromium-review.googlesource.com/569962Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46630}
      199a26f7
    • Clemens Hammacher's avatar
      [wasm] Don't store global handles in the interpreter · 5648aad5
      Clemens Hammacher authored
      Storing global handles in the interpreter is dangerous, because the
      global handles are strong roots into the heap. The interpreter itself is
      referenced from the heap via a Managed. Hence the interpreter keeps the
      instance alive, while the instance keeps the Managed alive. So the GC
      will never collect them.
      
      This CL refactors this to only store the handle to the instance object
      while executing in the interpreter, and clearing it when returning.
      It also removes the cache of import wrappers, as it should not be
      performance critical, but keeps lots of objects alive. If it turns out
      to be performance critical, we will have to reintroduce such a cache
      stored in the WasmDebugInfo object.
      
      R=titzer@chromium.org
      CC=ahaas@chromium.org
      
      Bug: chromium:610330
      Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
      Reviewed-on: https://chromium-review.googlesource.com/567058Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46629}
      5648aad5
  36. 07 Jul, 2017 1 commit
    • titzer's avatar
      [wasm] Introduce instance types for WebAssembly.* objects. · 17001a05
      titzer authored
      This CL refactors the internal representation of JavaScript-exposed
      WebAssembly objects to be more like other such objects in V8. By introducing
      a new instance type for each of the JS-exposed types, we get more robust
      typechecking without using embedder fields (which were previously used
      when these objects where instance type JS_API_OBJECT).
      
      In addition to the new instance types, the subclasses X of JSObject
      (WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
      now have appropriate Is##X() methods on Object and are now robust.
      
      BUG=v8:6547
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2964943002
      Cr-Commit-Position: refs/heads/master@{#46475}
      17001a05
  37. 09 Jun, 2017 1 commit