Skip to content

V
V8
Switch branch/tag
  1. 06 Sep, 2017 1 commit
  3. 05 Sep, 2017 1 commit
  5. 29 Aug, 2017 1 commit
  7. 25 Aug, 2017 1 commit
  9. 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
  11. 03 Aug, 2017 2 commits
  13. 01 Aug, 2017 1 commit
  15. 27 Jun, 2017 1 commit
  17. 26 Jun, 2017 1 commit
  19. 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
  21. 09 Jun, 2017 1 commit
  23. 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
  25. 10 May, 2017 1 commit
  27. 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
  29. 19 Apr, 2017 1 commit
  31. 13 Apr, 2017 1 commit
  33. 12 Apr, 2017 1 commit
  35. 07 Apr, 2017 1 commit
  37. 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
  39. 02 Mar, 2017 1 commit
  41. 21 Feb, 2017 1 commit
  43. 02 Feb, 2017 1 commit
    • yangguo's avatar
      [debugger] account for inlined functions when stepping. · d9399cc3
      yangguo authored 
      - Remove obsolete BreakLocatorType.
- Perform PrepareStepOnThrow after OnException event, in case stepping
  was scheduled in the exception event.
- Use frame count instead of frame pointer for stepping. Frame pointer
  is not reliable due to possible deopts.
- Consistently check for inlined functions in inlined frames.
- Use SharedFunctionInfo in FloodWithOneshot and EnsureDebugInfo.

R=jgruber@chromium.org
BUG=v8:5901

Review-Url: https://codereview.chromium.org/2664793002
Cr-Commit-Position: refs/heads/master@{#42878}
      d9399cc3
  45. 24 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Implement stepping in wasm code · 3dea55b4
      clemensh authored 
      Implement stepping by remembering the current step action in the wasm
interpreter handle in WasmDebugInfo, and using it when continuing
execution in the interpreter.
The control flow is as follows: After module compilation, the user sets
a breakpoint in wasm. The respective function is redirected to the
interpreter and the breakpoint is set on the interpreter. When it is
hit, we notify all debug event listeners, which might prepare stepping.
When returning from these listeners, before continuing execution, we
check whether stepping was requested and continue execution in the
interpreter accordingly.

Stepping from Wasm to JS and vice versa will be implemented and tested
in a follow-up CL. Testing this requires breakpoints and stepping in
Wasm to be exposed via the inspector interface, such that we can write
an inspector test. This mixed JS-Wasm-execution is hard to set up in a
cctest.

R=titzer@chromium.org, yangguo@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2649533002
Cr-Commit-Position: refs/heads/master@{#42624}
      3dea55b4
  47. 19 Jan, 2017 1 commit
    • clemensh's avatar
      Clarify the order of frame summaries and rename getters · 453a1df2
      clemensh authored 
      Document that frame summaries are bottom-to-top, i.e. caller before
callee, rename FrameSummary::GetFirst to FrameSummary::GetBottom and
introduce FrameSummary::GetTop.
For debugged JavaScript frames, it does not really matter which of the
functions we call, so I replaced a few GetFirst by GetTop instead of
GetBottom because it matches the semantics more closely.

This CL also reverts part of http://crrev.com/2621953002 by changing
BreakLocation::FromFrame back to accept a DebugInfo and a
JavaScriptFrame. We don't plan to create BreakLocations for wasm.

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

Review-Url: https://codereview.chromium.org/2647433002
Cr-Commit-Position: refs/heads/master@{#42505}
      453a1df2
  49. 13 Jan, 2017 3 commits
  51. 12 Jan, 2017 1 commit
    • clemensh's avatar
      Refactor FrameSummary for JS and Wasm frames · df5417ae
      clemensh authored 
      Wasm frames can be either compiled or interpreted. For interpreted wasm
frames, there is only one physical stack frame representing an
arbitrary stack of interpreted functions. Hence the physical stack
frame needs to provide a summary of the underlying functions.
Summaries were tailored for JavaScript frames before. Now they are
universal.

The refactored FrameSummaries are now also used in the FrameInspector,
and from the StackFrame objects themselves, to avoid code duplication.

All dispatch is implemented "manually", making the FrameSummary still
stack-allocatable.

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

Review-Url: https://codereview.chromium.org/2619353006
Cr-Commit-Position: refs/heads/master@{#42279}
      df5417ae
  53. 11 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Introduce WasmToInterpreterFrame · 81700ddf
      clemensh authored 
      and rename WasmFrame to WasmCompiledFrame.
The WasmToInterpreterFrames are not used yet; this will follow in a
follow-up CL (see tracking bug for the overall picture).
Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
call from wasm code to the wasm interpreter, implemented in C++.
They will support the Summarize method to inspect the stack frames in
the wasm interpreter.

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

Review-Url: https://codereview.chromium.org/2623773004
Cr-Commit-Position: refs/heads/master@{#42213}
      81700ddf
  55. 19 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Always provide a wasm instance object at runtime · 21a85c4a
      clemensh authored 
      When executing wasm code for testing, we did not create a
WasmInstanceObject and link it to the generated code. This required
some special handling at runtime (mainly for stack trace generation).
This CL always provides the WasmInstanceObject, such that e.g. function
names can be resolved the usual way.
The module bytes referenced by the WasmCompiledModule linked with the
WasmInstanceObject do not hold a valid wasm module yet. Instead, we
just add the bytes we need, and make the objects in WasmModule point to
those bytes (currently only used for function names). Those bytes will
not be parsed at runtime anyway.

R=titzer@chromium.org
CC=jgruber@chromium.org
BUG=v8:5620

Review-Url: https://codereview.chromium.org/2551053002
Cr-Commit-Position: refs/heads/master@{#41809}
      21a85c4a
  57. 12 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Handle potentially null callee-pc · c69b48ad
      clemensh authored 
      This only happens if there is a asm.js-wasm-frame on top of the stack
trace, which was not covered by our tests so far. The regression test
create a stack overflow in asm.js code, triggering this case.

R=mstarzinger@chromium.org
CC=titzer@chromium.org, bradnelson@chromium.org
BUG=chromium:673241

Review-Url: https://codereview.chromium.org/2562333002
Cr-Commit-Position: refs/heads/master@{#41639}
      c69b48ad
  59. 09 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Fix location for error in asm.js ToNumber conversion · 890d28f3
      clemensh authored 
      In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").

This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
  operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
  table, but two (one for the call, one for the parent which does the
  type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
  two calls in the WASM_TO_JS wrapper (only if the module origin is
  asm.js).
- the StackFrame::State struct now also holds the callee_pc_address,
  which is set in ComputeCallerState. The WASM frame uses this
  information to determine whether the callee frame is WASM_TO_JS, and
  whether that frame is at the ToNumber conversion call.
- the same information is also stored in the FrameArray which is used
  to reconstruct the stack trace later.

R=titzer@chromium.org, bradnelson@chromium.org
CC=jgruber@chromium.org
BUG=v8:4203,v8:5724

Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
Review-Url: https://codereview.chromium.org/2555243002
Cr-Original-Commit-Position: refs/heads/master@{#41599}
Cr-Commit-Position: refs/heads/master@{#41613}
      890d28f3
  61. 08 Dec, 2016 2 commits
    • clemensh's avatar
      Revert of [wasm] Fix location for error in asm.js ToNumber conversion... · d3d12541
      clemensh authored 
      Revert of [wasm] Fix location for error in asm.js ToNumber conversion (patchset #5 id:80001 of https://codereview.chromium.org/2555243002/ )

Reason for revert:
gc-stress failures

Original issue's description:
> [wasm] Fix location for error in asm.js ToNumber conversion
>
> In the asm.js code translated to wasm, we call imported functions via a
> WASM_TO_JS stub, which first calls the function and then calls ToNumber
> on the return value. Exceptions can happen in both calls.
> We were only ever reporting the location of the function call, whereas
> asm.js code executed via turbofan reported the location of the type
> coercion operator ("+" on "+foo()" or "|" on "foo()|0").
>
> This CL implements the same behaviour for asm.js code translated to
> wasm. The following is changed:
> - the AsmWasmBuilder records the parent node when descending on a binary
>   operator (also "+foo()" is represented by a binary operation).
> - it stores not one location per call in the source position side
>   table, but two (one for the call, one for the parent which does the
>   type coercion).
> - the wasm compiler annotates the source positions "0" and "1" to the
>   two calls in the WASM_TO_JS wrapper (only if the module origin is
>   asm.js).
> - during stack trace generation (in the StackTraceIterator), when we
>   move from the WASM_TO_JS frame to the WASM frame, we remember at which
>   call inside the WASM_TO_JS wrapper we are, and encode this information
>   in the generated caller state, used for the WASM frame.
> - the same information is also stored in the FrameArray which is used
>   to reconstruct the stack trace later.
>
> R=titzer@chromium.org, bradnelson@chromium.org
> CC=jgruber@chromium.org
> BUG=v8:4203,v8:5724
>
> Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
> Cr-Commit-Position: refs/heads/master@{#41599}

TBR=bradnelson@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4203,v8:5724

Review-Url: https://codereview.chromium.org/2563613003
Cr-Commit-Position: refs/heads/master@{#41601}
      d3d12541
    • clemensh's avatar
      [wasm] Fix location for error in asm.js ToNumber conversion · 94cd46b5
      clemensh authored 
      In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").

This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
  operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
  table, but two (one for the call, one for the parent which does the
  type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
  two calls in the WASM_TO_JS wrapper (only if the module origin is
  asm.js).
- during stack trace generation (in the StackTraceIterator), when we
  move from the WASM_TO_JS frame to the WASM frame, we remember at which
  call inside the WASM_TO_JS wrapper we are, and encode this information
  in the generated caller state, used for the WASM frame.
- the same information is also stored in the FrameArray which is used
  to reconstruct the stack trace later.

R=titzer@chromium.org, bradnelson@chromium.org
CC=jgruber@chromium.org
BUG=v8:4203,v8:5724

Review-Url: https://codereview.chromium.org/2555243002
Cr-Commit-Position: refs/heads/master@{#41599}
      94cd46b5
  63. 07 Dec, 2016 1 commit
    • lpy's avatar
      [Tracing] Implement IC statistics in tracing. · 0a3c8fc3
      lpy authored 
      This patch introduces:

1. ICStats class to store ic statistics items produced by V8,
2. A disabled by default tracing category v8.ic_stats,
3. An trace event V8.ICStats that contains ic statistics items in args,

We store ic statistics items in an array until the array is full to reduce
the number of trace events.

TBR=jkummerow@chromium.org,ishell@chromium.org

Review-Url: https://codereview.chromium.org/2503183002
Cr-Commit-Position: refs/heads/master@{#41559}
      0a3c8fc3
  65. 25 Nov, 2016 1 commit