Skip to content

V
V8
Switch branch/tag
  1. 23 Aug, 2018 1 commit
  3. 29 May, 2018 1 commit
  5. 06 Apr, 2018 1 commit
  7. 04 Apr, 2018 1 commit
  9. 21 Mar, 2018 1 commit
  11. 13 Dec, 2017 1 commit
    • Alexei Filippov's avatar
      [cpu-profiler] Introduce NativeFrame type. · f514cc96
      Alexei Filippov authored 
      The new frame type is inteneded to represent native C++ stack frames.
JS code may sometimes make calls to helper native functions that do not
provide any special stack layout besides the return address and frame pointer.

Currently the stack iterator bails out when it sees an unknown frame.
The patch allows the iterator to unwind stacks having such frames.

BUG=chromium:768540

Change-Id: I9c273c7015695a6733c0a0c52b522fca7b25de0d
Reviewed-on: https://chromium-review.googlesource.com/794991
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50058}
      f514cc96
  13. 22 Nov, 2017 1 commit
  15. 13 Oct, 2017 1 commit
  17. 15 Sep, 2017 1 commit
  19. 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
  21. 03 Aug, 2017 2 commits
  23. 18 Jul, 2017 1 commit
  25. 10 Jul, 2017 1 commit
  27. 26 Jun, 2017 1 commit
  29. 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
  31. 21 Feb, 2017 1 commit
  33. 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
  35. 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
  37. 30 Aug, 2016 1 commit
    • jgruber's avatar
      Fix LookupCode for the DatePrototype_GetField builtin · 4f781d72
      jgruber authored 
      This was exposed on win64 and manifested as a negative offset during
stack frame collection, i.e. pc < Code::instruction_start() for a
BUILTIN frame.

This happened because StackFrame::LookupCode returns the wrong code
object when call is the last instruction in a code object:
* pc is actually the return address for all but the topmost frame.
* pc points at the next instruction after the call.
* This is beyond the current code object if call is the last
  instruction.
* Lookup itself is naive in that it just returns the first code object
  for which (next_code_obj_addr > pc). It does not check that pc is
  actually within [instruction_start, instruction_end[.
* In this specific case, the pc (== return address) actually pointed
  at the beginning of the header of the next code object.
* We finally calculated offset as (code->instruction_start() - pc),
  but with the wrong code object.

This should be followed up by a proper fix at some point. For instance,
this could be setting pc to (return address - 1) for all but the topmost
frame.

BUG=v8:5311

Review-Url: https://codereview.chromium.org/2284673002
Cr-Commit-Position: refs/heads/master@{#38996}
      4f781d72
  39. 11 Jul, 2016 1 commit
  41. 04 Jul, 2016 1 commit
    • jgruber's avatar
      [builtins] Add receiver to builtin exit frames · f59a2335
      jgruber authored 
      Stack trace generation requires access to the receiver; and while the
receiver is already on the stack, we cannot determine its position
during stack trace generation (it's stored in argv[0], and argc is only
stored in a callee-saved register).

This patch grants access to the receiver by pushing argc onto builtin
exit frames as an extra argument. Compared to simply pushing the
receiver, this requires an additional dereference during stack trace
generation, but one fewer during builtin calls.

BUG=v8:4815

Review-Url: https://codereview.chromium.org/2106883003
Cr-Commit-Position: refs/heads/master@{#37500}
      f59a2335
  43. 30 Jun, 2016 1 commit
    • jgruber's avatar
      [builtins] New frame type for exits to C++ builtins · 5febc27b
      jgruber authored 
      Prior to this commit, calls to C++ builtins created standard exit
frames, which are skipped when constructing JS stack traces. In order to
show these calls on traces, we introduce a new builtin exit frame type.

Builtin exit frames contain target and new.target on the stack and are
not skipped during stack trace construction.

BUG=v8:4815
R=bmeurer@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg

Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
Review-Url: https://codereview.chromium.org/2090723005
Cr-Original-Commit-Position: refs/heads/master@{#37384}
Cr-Commit-Position: refs/heads/master@{#37416}
      5febc27b
  45. 29 Jun, 2016 3 commits
  47. 17 Jun, 2016 1 commit
    • jgruber's avatar
      [builtins] Introduce a proper BUILTIN frame type. · f47b9e98
      jgruber authored 
      This adds a new BUILTIN frame type, which supports variable number of
arguments for builtins implemented in hand-written native code (we will
extend this mechanism to TurboFan builtins at some point). Convert the
Math.max and Math.min builtins to construct a BUILTIN frame if required.

This does not yet work for C++ builtins, but that'll be the next step.

R=bmeurer@chromium.org, jarin@chromium.org
BUG=v8:4815
LOG=n

Review-Url: https://codereview.chromium.org/2069423002
Cr-Commit-Position: refs/heads/master@{#37051}
      f47b9e98
  49. 06 Apr, 2016 1 commit
    • clemensh's avatar
      Prepare StackFrame hierarchy & iterators for WASM · 08454486
      clemensh authored 
      This particularly changes the StackTraceFrameIterator such that is not
only returs JavaScriptFrames, but also WasmFrames. Because of that,
some methods (Summarize, function, receiver) were pulled up to the
StandardFrame, with specializations in JavaScriptFrame and WasmFrame.

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

Review URL: https://codereview.chromium.org/1861283002

Cr-Commit-Position: refs/heads/master@{#35293}
      08454486
  51. 29 Mar, 2016 1 commit
  53. 10 Mar, 2016 1 commit
    • joransiu's avatar
      S390: Platform specific includes in common files · daea0e75
      joransiu authored 
      Add S390 platform specific \#includes across various common files.
Add S390 CPU features to enum.
Add S390 implementation to extract sp/fp/pc from signal context.

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1777593003

Cr-Commit-Position: refs/heads/master@{#34674}
      daea0e75
  55. 08 Mar, 2016 1 commit
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored 
      Before this CL, various code stubs used different techniques
for marking their frames to enable stack-crawling and other
access to data in the frame. All of them were based on a abuse
of the "standard" frame representation, e.g. storing the a
context pointer immediately below the frame's fp, and a
function pointer after that. Although functional, this approach
tends to make stubs and builtins do an awkward, unnecessary
dance to appear like standard frames, even if they have
nothing to do with JavaScript execution.

This CL attempts to improve this by:

* Ensuring that there are only two fundamentally different
  types of frames, a "standard" frame and a "typed" frame.
  Standard frames, as before, contain both a context and
  function pointer. Typed frames contain only a minimum
  of a smi marker in the position immediately below the fp
  where the context is in standard frames.
* Only interpreted, full codegen, and optimized Crankshaft and
  TurboFan JavaScript frames use the "standard" format. All
  other frames use the type frame format with an explicit
  marker.
* Typed frames can contain one or more values below the
  type marker. There is new magic macro machinery in
  frames.h that simplifies defining the offsets of these fields
  in typed frames.
* A new flag in the CallDescriptor enables specifying whether
  a frame is a standard frame or a typed frame. Secondary
  register location spilling is now only enabled for standard
  frames.
* A zillion places in the code have been updated to deal with
  the fact that most code stubs and internal frames use the
  typed frame format. This includes changes in the
  deoptimizer, debugger, and liveedit.
* StandardFrameConstants::kMarkerOffset is deprecated,
  (CommonFrameConstants::kContextOrFrameTypeOffset
  and StandardFrameConstants::kFrameOffset are now used
  in its stead).

LOG=N

Review URL: https://codereview.chromium.org/1696043002

Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  57. 04 Mar, 2016 1 commit
  59. 23 Feb, 2016 3 commits
  61. 16 Oct, 2015 1 commit
    • rmcilroy's avatar
      [Interpreter]: Basic support for iterating interpreter stack frames for GC. · 4b2fffae
      rmcilroy authored 
      Adds basic support for iterating interpreter stack frames for GC. Currently
InterpreterStackFrames are treated just like JavaScriptStackFrames since the
JavaScriptFrame::IterateExpressions() will correctly iterate over all the
local / temp interpeter Registers, and will iterate over the
interpreter_entry_trampoline pc address. There is no need to explicitly
iterate over the BytecodeArray object since that is held in a machine
register in the bytecode handler which is marked as kMachTaggedAny by
TurboFan, and so will get iterated appropriately when iterating the
bytecode handler stub's stack frame.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1407513003

Cr-Commit-Position: refs/heads/master@{#31342}
      4b2fffae
  63. 30 Sep, 2015 1 commit
  65. 01 Sep, 2015 1 commit
  67. 13 Jul, 2015 1 commit