Skip to content

V
V8
Switch branch/tag
  1. 10 Aug, 2017 1 commit
  3. 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
  5. 18 Jul, 2017 1 commit
  7. 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
  9. 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
  11. 10 Jul, 2017 1 commit
  13. 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
  15. 27 Jun, 2017 1 commit
  17. 26 Jun, 2017 1 commit
  19. 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
  23. 21 Jun, 2017 1 commit
  25. 12 Jun, 2017 4 commits
  27. 09 Jun, 2017 1 commit
  29. 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
  31. 22 May, 2017 1 commit
  33. 08 May, 2017 1 commit
  35. 28 Apr, 2017 1 commit
  37. 26 Apr, 2017 1 commit
  39. 25 Apr, 2017 1 commit
  41. 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
  43. 06 Apr, 2017 1 commit
  45. 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
  47. 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
  49. 20 Feb, 2017 1 commit
  51. 13 Feb, 2017 1 commit
  53. 27 Jan, 2017 1 commit
  55. 24 Jan, 2017 1 commit
  57. 16 Jan, 2017 1 commit
  59. 12 Jan, 2017 1 commit
  61. 21 Dec, 2016 1 commit
  63. 20 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmSharedModuleData and refactor other objects · 081ac370
      clemensh authored 
      The new object will hold information which is shared by all clones of a
WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
future also breakpoints. From there, we can set them on each new
instantiation of any clone.

While already changing lots of the code base, I also renamed all
getters from "get_foo" to "foo", to conform to the style guide.

R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:5732

Review-Url: https://codereview.chromium.org/2591653002
Cr-Commit-Position: refs/heads/master@{#41862}
      081ac370
  65. 30 Nov, 2016 1 commit
    • clemensh's avatar
      [wasm] Remove raw byte pointers from WasmModule · 6572b562
      clemensh authored 
      These byte pointers (module_start and module_end) were only valid
during decoding. During instantiation or execution, they can get
invalidated by garbage collection.
This CL removes them from the WasmModule struct, and introduces a new
ModuleStorage struct as interface to the wasm wire bytes.
Since the storage is often needed together with the ModuleEnv, a new
ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage.
The pointers in the ModuleStorage should never escape the live range of
this struct, as they might point into a SeqOneByteString or ArrayBuffer.
Therefore, the WasmInterpreter needs to create its own copy of the
whole module.
Runtime functions that previously used the raw pointers in WasmModule
(leading to memory errors) now have to use the SeqOneByteString in the
WasmCompiledModule.

R=titzer@chromium.org
BUG=chromium:669518

Review-Url: https://codereview.chromium.org/2540133002
Cr-Commit-Position: refs/heads/master@{#41388}
      6572b562
  67. 16 Nov, 2016 1 commit
  69. 14 Nov, 2016 1 commit