Skip to content

V
V8
Switch branch/tag
  1. 02 Feb, 2018 1 commit
  3. 23 Jan, 2018 1 commit
  5. 22 Jan, 2018 1 commit
  7. 19 Jan, 2018 1 commit
  9. 17 Jan, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Distinguish Liftoff code from Turbofan code · 41f231a2
      Clemens Hammacher authored 
      For memory tracing, output a 'T' for Turbofan code and an 'L' for
Liftoff code. To do this, the WasmCodeWrapper now has some dispatch
functions which work for both on-the-heap and off-the-heap code.
We can probably refactor more code by having this mechanism.

Since the output of --wasm-trace-memory differs now between Turbofan
and Liftoff, the message test is split in two.

R=titzer@chromium.org
CC=mstarzinger@chromium.org

Bug: v8:6600
Change-Id: Ic5fd18c631f5c8aaad19d639df75b18098895b5a
Reviewed-on: https://chromium-review.googlesource.com/868214Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50655}
      41f231a2
  11. 13 Dec, 2017 2 commits
  13. 29 Nov, 2017 1 commit
  15. 28 Nov, 2017 3 commits
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] JIT using WasmCodeManager"" · b03b1bd9
      Mircea Trofin authored 
      This reverts commit b301203e.

Reason for revert: Fixed issues on arm.

Original change's description:
> Revert "[wasm] JIT using WasmCodeManager"
> 
> This reverts commit d4c8393c.
> 
> Reason for revert: Breaks ARM hardware:
> https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268
> 
> Original change's description:
> > [wasm] JIT using WasmCodeManager
> > 
> > This is the first step towards wasm code sharing. This CL moves wasm
> > code generation outside the JavaScript GC heap using the previously -
> > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
> > flag).
> > 
> > See design document: go/wasm-on-native-heap-stage-1
> > 
> > This CL doesn't change other wasm architectural invariants. We still
> > have per-Isolate wasm code generation, and per-wasm module instance
> > code specialization.
> > 
> > Bug:v8:6876
> > 
> > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
> > Reviewed-on: https://chromium-review.googlesource.com/674086
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Eric Holk <eholk@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#49689}
> 
> TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
> 
> Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6876
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/794690
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49691}

TBR=bradnelson@chromium.org,machenbach@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: I1b07638d1bb2ba0664305b4b2dcfc1342dc8444f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6876
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/794434
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49692}
      b03b1bd9
    • Michael Achenbach's avatar
      Revert "[wasm] JIT using WasmCodeManager" · b301203e
      Michael Achenbach authored 
      This reverts commit d4c8393c.

Reason for revert: Breaks ARM hardware:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268

Original change's description:
> [wasm] JIT using WasmCodeManager
> 
> This is the first step towards wasm code sharing. This CL moves wasm
> code generation outside the JavaScript GC heap using the previously -
> introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
> flag).
> 
> See design document: go/wasm-on-native-heap-stage-1
> 
> This CL doesn't change other wasm architectural invariants. We still
> have per-Isolate wasm code generation, and per-wasm module instance
> code specialization.
> 
> Bug:v8:6876
> 
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
> Reviewed-on: https://chromium-review.googlesource.com/674086
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49689}

TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6876
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/794690Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49691}
      b301203e
    • Mircea Trofin's avatar
      [wasm] JIT using WasmCodeManager · d4c8393c
      Mircea Trofin authored 
      This is the first step towards wasm code sharing. This CL moves wasm
code generation outside the JavaScript GC heap using the previously -
introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
flag).

See design document: go/wasm-on-native-heap-stage-1

This CL doesn't change other wasm architectural invariants. We still
have per-Isolate wasm code generation, and per-wasm module instance
code specialization.

Bug:v8:6876

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
Reviewed-on: https://chromium-review.googlesource.com/674086Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49689}
      d4c8393c
  17. 27 Nov, 2017 1 commit
  19. 22 Nov, 2017 1 commit
  21. 18 Oct, 2017 1 commit
  23. 13 Oct, 2017 2 commits
  25. 15 Sep, 2017 1 commit
  27. 06 Sep, 2017 1 commit
  29. 05 Sep, 2017 1 commit
  31. 29 Aug, 2017 1 commit
  33. 25 Aug, 2017 1 commit
  35. 07 Aug, 2017 2 commits
    • Clemens Hammacher's avatar
      [wasm] [debug] Implement calling imported wasm functions · c39c6eba
      Clemens Hammacher authored 
      The interpreter was not able to call imported wasm functions (hitting
UNIMPLEMENTED). This CL fixes this by creating a "CWasmEntry", which is
signature-specific. It has JS linkage and receives the wasm code object
to call and a buffer containing all arguments (similar to the
interpreter entry). It loads all arguments from the buffer and calls the
given code object.
The c-wasm-entry code objects are cached per instance, such that we
only create them once per signature.

These wasm entry stubs will also allow us to call back to compiled code
from the interpreter, which we might want to do to reduce the slowdown
of executing wasm for debugging.

R=titzer@chromium.org

Bug: chromium:735792
Change-Id: I7fecec3a7bec62a9de40fff115b684759b12a28b
Reviewed-on: https://chromium-review.googlesource.com/600308
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47195}
      c39c6eba
    • Ben L. Titzer's avatar
      Simplifications to frames.h and frames.cc. · dc34289b
      Ben L. Titzer authored 
      Move unnecessarily public methods from frames.h into .cc file.
Remove dead StackFrame::SetCallerFp().

R=mstarzinger@chromium.org

Bug: 
Change-Id: I7b66a430cfb01bb38046c9e92f504134ba8316a3
Reviewed-on: https://chromium-review.googlesource.com/602271Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47181}
      dc34289b
  37. 03 Aug, 2017 2 commits
  39. 01 Aug, 2017 1 commit
  41. 27 Jun, 2017 1 commit
  43. 26 Jun, 2017 1 commit
  45. 15 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[frames] Make interpreted frame detection stricter (reland)" · 920796b3
      Leszek Swirski authored 
      This reverts commit b7a036a6.

Reason for revert: We don't want to ever access the heap when walking the stack

Original change's description:
> [frames] Make interpreted frame detection stricter (reland)
> 
> When iterating over stack frames, make the interpreted frame detection
> require that the frame header contains the bytecode array.
> 
> Currently, the stack frame iterator supports bytecode handlers that
> don't create stack frames by checking if the top of the stack (i.e. the
> return address) is the interpreter entry trampoline. However, optimized
> code tail called from the interpreter entry trampoline can move the
> stack pointer without clearing the stack, which means it can end up with
> a pointer into the interpreter entry trampoline on the top of its stack
> (in an uninitialized value), and be interpreted as an interpreted frame.
> 
> To avoid such optimized code frames being interpreted as interpreted
> frames, we now additionally test the frame header, to see if it contains
> a valid pointer to a BytecodeArray.
> 
> Reland of https://chromium-review.googlesource.com/c/535646/
> 
> Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a
> Reviewed-on: https://chromium-review.googlesource.com/536935
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45959}

TBR=kozyatinskiy@chromium.org,leszeks@chromium.org

Change-Id: I52a62c8e11af4d1565af92f10113b955f8c2c2f2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/536938Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45960}
      920796b3
    • Leszek Swirski's avatar
      [frames] Make interpreted frame detection stricter (reland) · b7a036a6
      Leszek Swirski authored 
      When iterating over stack frames, make the interpreted frame detection
require that the frame header contains the bytecode array.

Currently, the stack frame iterator supports bytecode handlers that
don't create stack frames by checking if the top of the stack (i.e. the
return address) is the interpreter entry trampoline. However, optimized
code tail called from the interpreter entry trampoline can move the
stack pointer without clearing the stack, which means it can end up with
a pointer into the interpreter entry trampoline on the top of its stack
(in an uninitialized value), and be interpreted as an interpreted frame.

To avoid such optimized code frames being interpreted as interpreted
frames, we now additionally test the frame header, to see if it contains
a valid pointer to a BytecodeArray.

Reland of https://chromium-review.googlesource.com/c/535646/

Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a
Reviewed-on: https://chromium-review.googlesource.com/536935Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45959}
      b7a036a6
  47. 09 Jun, 2017 1 commit
  49. 07 Jun, 2017 1 commit
    • danno's avatar
      Inline Array.prototype.forEach in TurboFan · 90c3a2d5
      danno authored 
      This CL contains a few pieces:

- A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
  graphs, which--when triggered--swizzle the values in the the FrameState to be
  parameters to a typically TF-generated builtin that resumes execution to finish
  the slow-case functionality.
- Continuation builtins that have special handling in the deoptimizer and their own
  new frame type to ensure that the values they need to begin executing can be stashed
  away and restored immediately before the builtin is called via a trampoline that runs
  when the continuation builtin's frame execution resumes.
- An implementation of Array.prototype.forEach in TurboFan that can be used to
  inline it. The inlined forEach implementation uses the checkpoints mechanism
  described above to deopt in the middle of the forEach in the cases that optimization
  invariants are violated. There is a slightly different continuation stub for each
  deopt point in the forEach implementation to ensure the correct side-effects, i.e.
  that the deopt of the builtin isn't programmatically observable.

Review-Url: https://codereview.chromium.org/2803853005
Cr-Commit-Position: refs/heads/master@{#45764}
      90c3a2d5
  51. 10 May, 2017 1 commit
  53. 25 Apr, 2017 1 commit
    • ulan's avatar
      Decouple root visitors from object visitors. · e671ed36
      ulan authored 
      This patch adds a new interface called RootVisitor and changes the root
iteration functions to accept a RootVisitor instead of an ObjectVisitor.

Future CLs will change ObjectVisitor to provide the host object to all
visiting functions, which will bring it in sync with static visitors.

Having separate visitors for roots and objects removes ambiguity in
VisitPointers and reduces chances of forgetting to record slots.

This is intended as pure refactoring. All places that require behavior
change are marked with TODO and will addressed in future CLs.

BUG=chromium:709075

Review-Url: https://codereview.chromium.org/2801073006
Cr-Commit-Position: refs/heads/master@{#44852}
      e671ed36
  55. 19 Apr, 2017 1 commit
  57. 13 Apr, 2017 1 commit
  59. 12 Apr, 2017 1 commit
  61. 07 Apr, 2017 1 commit
  63. 06 Apr, 2017 2 commits
    • Franziska Hinkelmann's avatar
      Revert "[builtins] don't inline calls for common Promise ops in async builtins" · c931820d
      Franziska Hinkelmann authored 
      This reverts commit 9461fe24.

Reason for revert: Breaks a test in Node.js: 
 parallel/test-util-inspect

=== release test-util-inspect ===                                              
Path: parallel/test-util-inspect
#
# Fatal error in , line 0
# unreachable code
#

==== C stack trace ===============================


Original change's description:
> [builtins] don't inline calls for common Promise ops in async builtins
> 
> InternalResolvePromise, InternalPromiseReject and
> InternalPerformPromiseThen generate quite a lot of code.
> 
> This change adds 3 new TF stubs which inline calls to these builtins.
> These stubs are invoked rather than inlining those operations listed
> above directly. This is done for Async Iteration builtins, as well as
> Async Function builtins. Promise builtins are left as they were, and
> continue to inline these calls.
> 
> This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
> release build.
> 
> BUG=v8:5855
> R=​gsathya@chromium.org, jgruber@chromium.org
> 
> Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
> Reviewed-on: https://chromium-review.googlesource.com/461269
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44445}

TBR=mstarzinger@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,v8-reviews@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5855

Change-Id: Iabcdf8b025cc9b053a858f8e74389638ac000ba0
Reviewed-on: https://chromium-review.googlesource.com/469946Reviewed-by: 's avatarFranziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44448}
      c931820d
    • Caitlin Potter's avatar
      [builtins] don't inline calls for common Promise ops in async builtins · 9461fe24
      Caitlin Potter authored 
      InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.

This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.

This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.

BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org

Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
Reviewed-on: https://chromium-review.googlesource.com/461269
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44445}
      9461fe24