1. 11 Oct, 2017 4 commits
  2. 05 Oct, 2017 1 commit
  3. 28 Sep, 2017 1 commit
  4. 25 Sep, 2017 1 commit
    • Karl Schimpf's avatar
      Add capability of throwing values in WASM · 49106e48
      Karl Schimpf authored
      This is a second attempt at landing CL 644866 which was reverted by
      CL 667019.
      
      Extends the current implementation of WASM exceptions to be able to
      throw exceptions with values (not just tags).
      
      A JS typed (uint_16) array is used to hold the thrown values. This
      allows all WASM types to be stored (i32, i64, f32, and f64) as well as
      be inspected in JS.
      
      The previous CL was reverted because the WASM compiler made calls to
      run time functions with tagged objects, which must not be done. To fix
      this, all run time calls use the thread-level isolate to hold the
      exception being processed.
      
      Bug: v8:6577
      Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
      Reviewed-on: https://chromium-review.googlesource.com/677056
      Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48148}
      49106e48
  5. 15 Sep, 2017 1 commit
  6. 13 Sep, 2017 1 commit
  7. 11 Sep, 2017 1 commit
  8. 08 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [fuzzer] Fix segfault · 3ced15cb
      Clemens Hammacher authored
      Even though we were generating additional arguments with default value
      in the case that the caller was not providing enough, we then passed
      the original pointer, leading to potential out-of-bounds accesses.
      
      R=ahaas@chromium.org
      
      Bug: chromium:763294,chromium:763297
      Change-Id: Id18622d0d40e0408e26a5fc6f97494b5f9e18d17
      Reviewed-on: https://chromium-review.googlesource.com/657699Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47930}
      3ced15cb
  9. 07 Sep, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Avoid executing infinite loops in the wasm fuzzers · 7b53a0e0
      Andreas Haas authored
      The wasm-async fuzzer uses the bytes provided by the fuzzer engine
      directly as wasm module bytes, compiles them with async compilation, and
      then tries to execute the "main" function of the module. This "main"
      can have an infinite loop which causes a timeout in the fuzzer. With
      this CL the "main" function is first executed with the interpreter. If
      the execution in the interpreter finishes within 16k steps, which means
      that there is no infinite loop, also the compiled code is executed.
      
      I added the raw fuzzer input as a test case because in this case I
      really want to test the fuzzer and not V8.
      
      R=clemensh@chromium.org
      
      Bug: chromium:761784
      Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162
      Reviewed-on: https://chromium-review.googlesource.com/651046
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47874}
      7b53a0e0
  10. 04 Sep, 2017 1 commit
  11. 10 Aug, 2017 1 commit
  12. 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
  13. 18 Jul, 2017 1 commit
  14. 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
  15. 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
  16. 10 Jul, 2017 1 commit
  17. 29 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Use pending exceptions consistently · d6aed443
      Clemens Hammacher authored
      In our internal code, we should only use pending exceptions. They will
      be converted to scheduled exceptions on the API boundary.
      Hence, the ErrorThrower just sets a pending exception; it should never
      have to think about scheduled exceptions. The new
      ScheduledErrorThrower inherits from ErrorThrower and reschedules any
      pending exceptions in its destructor (turning them into scheduled
      exceptions).
      In some situations, there might already be a scheduled exception, e.g.
      when calling other API methods (v8::Value::Get). In this case, the
      ErrorThrower should also not set another pending exception. For the
      reasons mentioned above, this can only be handled in the
      ScheduledErrorThrower, which is used the API methods.
      
      This fixes one DCHECK failure and one TODO about scheduled exceptions
      if no instance can be created, because the start function throws.
      
      R=mtrofin@chromium.org, mstarzinger@chromium.org
      BUG=v8:6232,chromium:736256
      
      Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
      Reviewed-on: https://chromium-review.googlesource.com/548641
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46314}
      d6aed443
  18. 27 Jun, 2017 1 commit
  19. 26 Jun, 2017 1 commit
  20. 23 Jun, 2017 2 commits
  21. 22 Jun, 2017 1 commit
    • kschimpf's avatar
      Fix use of history timers in background threads. · d4a10807
      kschimpf authored
      HistoryTimer's can't run in the background because they use a timer
      with a simple api of Start() and Stop(). This CL fixes this problem
      by building a base class TimedHistogram that doesn't have a timer.
      
      The class HistoryTimer is modified to use this base class so that
      uses that run on the foreground thread do not need to be modified.
      
      It also adds a new class TimedHistogramScope that defines the timer
      in this class. This allows the corresopnding TimedHistogram class to
      be type safe.
      
      BUG=v8:6361
      
      Review-Url: https://codereview.chromium.org/2929853003
      Cr-Commit-Position: refs/heads/master@{#46150}
      d4a10807
  22. 21 Jun, 2017 1 commit
  23. 12 Jun, 2017 4 commits
  24. 09 Jun, 2017 1 commit
  25. 31 May, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Make prototype flags experimental · 45618a9a
      Clemens Hammacher authored
      Most prototype implementations are not fully supported in the
      interpreter. This is the case at least for exception handling, simd, and
      atomics. Any function can be redirected to the interpreter though,
      either by passing --wasm-interpret-all, or by dynamically redirecting to
      the interpreter for debugging.
      Making the flags experimental keeps the fuzzer from playing around with
      these flags.
      
      Drive-by: Refactor tests which explicitly set the prototype flag to use
      a new scope for that.
      
      R=ahaas@chromium.org
      BUG=chromium:727584
      
      Change-Id: I67da79f579f1ac93c67189afef40c6524bdd4430
      Reviewed-on: https://chromium-review.googlesource.com/519402
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45639}
      45618a9a
  26. 22 May, 2017 1 commit
  27. 08 May, 2017 1 commit
  28. 28 Apr, 2017 1 commit
  29. 26 Apr, 2017 1 commit
  30. 25 Apr, 2017 1 commit
  31. 10 Apr, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Refactor wasm::Result type · d50ebde7
      Clemens Hammacher authored
      - Store std::string instead of std::unique_ptr<char[]> for the error
        message.
      - Remove ErrorCode, which was just kSuccess and kError anyway. Error is
        now detected on whether error_msg_ is empty or not.
      - Refactor constructors for perfect forwarding; this will allow us to
        implement Result<std::unique_ptr<X*>>.
      - Refactor Decoder::toResult for perfect forwarding.
      - Remove output operators (operator<<) for Result; it was only used in
        the error case anyway. Print error message directly instead.
        The operator was problematic since it assumed the existence of an
        output operator for every T which is used in Result<T>.
      - Remove ModuleError and FunctionError, introduce general static
        Result<T>::Error method instead.
      
      R=ahaas@chromium.org
      
      Change-Id: I1e0f602a61ee9780fee2a3ed33147d431fb092ba
      Reviewed-on: https://chromium-review.googlesource.com/472748
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44518}
      d50ebde7
  32. 06 Apr, 2017 1 commit