Skip to content

V
V8
Switch branch/tag
  1. 28 Sep, 2017 1 commit
  3. 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
  7. 13 Sep, 2017 1 commit
  9. 11 Sep, 2017 1 commit
  11. 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
  13. 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
  15. 04 Sep, 2017 1 commit
  17. 10 Aug, 2017 1 commit
  19. 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
  21. 18 Jul, 2017 1 commit
  23. 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
  25. 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
  27. 10 Jul, 2017 1 commit
  29. 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
  31. 27 Jun, 2017 1 commit
  33. 26 Jun, 2017 1 commit
  35. 23 Jun, 2017 2 commits
  37. 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
  39. 21 Jun, 2017 1 commit
  41. 12 Jun, 2017 4 commits
  43. 09 Jun, 2017 1 commit
  45. 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
  47. 22 May, 2017 1 commit
  49. 08 May, 2017 1 commit
  51. 28 Apr, 2017 1 commit
  53. 26 Apr, 2017 1 commit
  55. 25 Apr, 2017 1 commit
  57. 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
  59. 06 Apr, 2017 1 commit
  61. 23 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Implement indirect function calls · b8f88601
      Clemens Hammacher authored 
      This CL adds support for indirect function calls to the interpreter. It
can indirectly call other wasm function in the same instance, which are
then executed in the interpreter, or call imported functions.

Implementing this required some refactoring:
- The wasm interpreter now unwraps import wrappers on demand, instead
  of unwrapping all of them on instantiation and storing a vector of
  handles. This also avoids the DeferredHandleScope completely, instead
  we just store two global handles in the code map.
- The interpreter gets the code table, function tables and signature
  tables directly from the attached wasm instance object. This ensures
  that the interpreter sees all updates to tables that might have been
  performed by external code.
- There is now common functionality for calling a code object. This is
  used for direct calls to imported functions and for all indirect
  calls. As these code objects can also be wasm functions which should
  be executed in the interpreter itself, I introduce a struct to hold
  the outcome of calling the code object, or a pointer to
  InterpreterCode to be called in the interpreter.

R=ahaas@chromium.org
BUG=v8:5822

Change-Id: I20fb2ea007e79e5fcff9afb4b1ca31739ebcb83f
Reviewed-on: https://chromium-review.googlesource.com/458417
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44059}
      b8f88601
  63. 14 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Cleanup wasm interpreter · 0a4c5c44
      Clemens Hammacher authored 
      This is a cleanup in preparation to implement calling imported
functions via the wasm interpreter.
For imported functions, we do not create entries in the
interpreter_code_ vector any more.

I also simplified the interface and removed unused or redundant return
values. More things are now DCHECKed instead of bailing out.

Also, we previously had two PushFrame methods: One is supposed to
initialize the interpreter from external code (i.e. adds the first
frame to the stack), the other one is used to push new frames on the
frame stack for called functions. This CL renames the first to
InitFrame, and makes it use the second one. The other remaining user is
the DoCall method.

R=titzer@chromium.org
BUG=v8:5822

Change-Id: Id09ff1e3256428fbd8c955e4664507a0c3167e53
Reviewed-on: https://chromium-review.googlesource.com/453482
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43793}
      0a4c5c44
  65. 20 Feb, 2017 1 commit
  67. 13 Feb, 2017 1 commit
  69. 27 Jan, 2017 1 commit