Skip to content

V
V8
Switch branch/tag
  1. 14 Apr, 2016 2 commits
  3. 06 Apr, 2016 2 commits
    • 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
    • bmeurer's avatar
      [generators] Decouple generator resume from fullcodegen. · 974721c6
      bmeurer authored 
      Introduce a ResumeGeneratorTrampoline, which does the actual stack state
reconstruction (currently always restores a fullcodegen frame), and
introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
%GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
this native builtin.

Also unify the flooding in case of step-in to always work based on
JSFunction and remove the special casing for JSGeneratorObject.

R=mstarzinger@chromium.org, neis@chromium.org
TBR=rossberg@chromium.org
BUG=chromium:513471
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#35283}
      974721c6
  5. 05 Apr, 2016 2 commits
  7. 29 Mar, 2016 1 commit
  9. 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
  11. 04 Mar, 2016 1 commit
  13. 23 Feb, 2016 3 commits
  15. 18 Feb, 2016 1 commit
  17. 17 Feb, 2016 2 commits
  19. 16 Feb, 2016 2 commits
  21. 11 Feb, 2016 1 commit
  23. 05 Feb, 2016 1 commit
  25. 04 Feb, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Switch context during stack unwinding. · 76bfc16b
      mstarzinger authored 
      This implements proper context switching while unwinding the stack due
to an exception being handled in interpreted code. The context under
which the handler is scoped is being preserved in a dedicated register
while the try-block is running. Both, the stack unwinding machinery as
well as the graph builder, restore the context from that register.

R=rmcilroy@chromium.org,bmeurer@chromium.org
BUG=v8:4674
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33733}
      76bfc16b
  27. 28 Jan, 2016 1 commit
  29. 20 Jan, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] First implementation of stack unwinding. · 0b3066b8
      mstarzinger authored 
      This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.

R=rmcilroy@chromium.org,oth@chromium.org
BUG=v8:4674
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33414}
      0b3066b8
  31. 18 Dec, 2015 1 commit
    • rmcilroy's avatar
      [Interpreter] Add basic deoptimization support from TurboFan to Ignition. · b10d24ff
      rmcilroy authored 
      Adds support for generating deoptimization translations for interpreter
stack frames, and building interpreter frames for these translations
when a function deopts. Also adds builtins for
InterpreterNotifyDeoptimized which resume the function's continuation at
the correct point in the interpreter after deopt.

MIPS patch contributed by balazs.kilvady@igmtec.com

BUG=v8:4280
LOG=N
TEST=test-deoptimization.cc with --ignition and --turbo

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

Cr-Commit-Position: refs/heads/master@{#32971}
      b10d24ff
  33. 16 Dec, 2015 1 commit
  35. 03 Dec, 2015 1 commit
  37. 25 Nov, 2015 1 commit
    • mstarzinger's avatar
      [interpreter] Switch passing of new.target to register. · 3d004eea
      mstarzinger authored 
      This passes the new.target value in a register instead of through a
side-channel via the construct stub. The interpreter entry trampoline
stores this value in a bytecode register so that it can be accessed
directly by the interpreter. The size of the interpreter stack frame
hence grows by one slot.

R=oth@chromium.org
BUG=v8:4544
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32264}
      3d004eea
  39. 13 Nov, 2015 1 commit
  41. 03 Nov, 2015 1 commit
  43. 22 Oct, 2015 1 commit
    • rmcilroy's avatar
      [Interpreter] Fill out function prologue support. · 6256e1dc
      rmcilroy authored 
      Fills out some more of the function prologue support in the
interpreter. Deals with creation of arguments objects and throwing
IllegalRedeclarations if necessary. Also adds (untested) support for
this.function and new.target variable assignment.

Also fixes a bug in Frames::is_java_script() to deal with
interpreter frames correctly.

Cleans up comments in builtins InterpreterEntryTrampoline about
missing prologue support.

Adds the following bytecodes:
  - CreateArgumentsSloppy
  - CreateArgumentsStrict

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#31486}
      6256e1dc
  45. 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
  47. 07 Oct, 2015 1 commit
  49. 30 Sep, 2015 1 commit
  51. 16 Sep, 2015 1 commit
  53. 02 Sep, 2015 1 commit
  55. 31 Aug, 2015 1 commit
  57. 28 Aug, 2015 1 commit
  59. 27 Aug, 2015 1 commit
  61. 18 Aug, 2015 1 commit
    • danno's avatar
      [turbofan] Unify referencing of stack slots · cbbaf9ea
      danno authored 
      Previously, it was not possible to specify StackSlotOperands for all
slots in both the caller and callee stacks. Specifically, the region
of the callee's stack including the saved return address, frame
pointer, function pointer and context pointer could not be addressed
by the register allocator/gap resolver.

In preparation for better tail call support, which will use the gap
resolver to reconcile outgoing parameters, this change makes it
possible to address all slots on the stack, because slots in the
previously inaccessible dead zone may become parameter slots for
outgoing tail calls. All caller stack slots are accessible as they
were before, with slot -1 corresponding to the last stack
parameter. Stack slot indices >= 0 access the callee stack, with slot
0 corresponding to the callee's saved return address, 1 corresponding
to the saved frame pointer, 2 corresponding to the current function
context, 3 corresponding to the frame marker/JSFunction, and slots 4
and above corresponding to spill slots.

The following changes were specifically	needed:

* Frame	has been changed to explicitly manage three areas of the
  callee frame, the fixed header, the spill slot area, and the
  callee-saved register area.
* Conversions from stack slot indices to fp offsets all now go through
  a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
* The generation of deoptimization translation tables has been changed
  to support the new stack slot indexing scheme. Crankshaft, which
  doesn't support the new slot numbering in its register allocator,
  must adapt the indexes when creating translation tables.
* Callee-saved parameters are now kept below spill slots, not above,
  to support saving only the optimal set of used registers, which is
  only known after register allocation is finished and spill slots
  have been allocated.

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

Cr-Commit-Position: refs/heads/master@{#30224}
      cbbaf9ea
  63. 17 Jul, 2015 1 commit
  65. 10 Jul, 2015 1 commit