Skip to content

V
V8
Switch branch/tag
  1. 03 Dec, 2015 1 commit
  3. 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
  5. 13 Nov, 2015 1 commit
  7. 03 Nov, 2015 1 commit
  9. 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
  11. 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
  13. 07 Oct, 2015 1 commit
  15. 30 Sep, 2015 1 commit
  17. 16 Sep, 2015 1 commit
  19. 02 Sep, 2015 1 commit
  21. 31 Aug, 2015 1 commit
  23. 28 Aug, 2015 1 commit
  25. 27 Aug, 2015 1 commit
  27. 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
  29. 17 Jul, 2015 1 commit
  31. 10 Jul, 2015 1 commit
  33. 07 Jul, 2015 1 commit
  35. 06 Jul, 2015 1 commit
  37. 16 Jun, 2015 1 commit
  39. 10 Jun, 2015 1 commit
  41. 09 Jun, 2015 1 commit
  43. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  45. 03 Jun, 2015 1 commit
  47. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  49. 29 May, 2015 1 commit
  51. 25 Mar, 2015 1 commit
    • mstarzinger's avatar
      Switch full-codegen from StackHandlers to handler table. · 38a719f9
      mstarzinger authored 
      This switches full-codegen to no longer push and pop StackHandler
markers onto the operand stack, but relies on a range-based handler
table instead. We only use StackHandlers in JSEntryStubs to mark the
transition from C to JS code.

Note that this makes deoptimization and OSR from within any try-block
work out of the box, makes the non-exception paths faster and should
overall be neutral on the memory footprint (pros).

On the other hand it makes the exception paths slower and actually
throwing and exception more expensive (cons).

R=yangguo@chromium.org
TEST=cctest/test-run-jsexceptions/DeoptTry

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

Cr-Commit-Position: refs/heads/master@{#27440}
      38a719f9
  53. 18 Mar, 2015 1 commit
    • mstarzinger's avatar
      Remove kind field from StackHandler. · 15f82138
      mstarzinger authored 
      This relands commit 96f79568.

This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.

There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.

With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27263}
      15f82138
  55. 16 Mar, 2015 2 commits
    • mstarzinger's avatar
      Revert of Remove kind field from StackHandler. (patchset #4 id:60001 of... · 5977ed02
      mstarzinger authored 
      Revert of Remove kind field from StackHandler. (patchset #4 id:60001 of https://codereview.chromium.org/1002203002/)

Reason for revert:
Layout test failure in inspector/sources/debugger/debugger-pause-on-promise-rejection.html

Original issue's description:
> Remove kind field from StackHandler.
>
> This makes the Isolate::Throw logic not depend on a prediction of
> whether an exception is caught or uncaught. Such a prediction is
> inherently undecidable because a finally block can decide between
> consuming or re-throwing an exception depending on arbitray control
> flow.
>
> There still is a conservative prediction mechanism in place that
> components like the debugger or tracing can use for reporting.
>
> With this change we can get rid of the StackHandler::kind field, a
> pre-requisite to do table-based lookups of exception handlers.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/96f79568a926966ebcf0685bf9adc947f4e1fbff
> Cr-Commit-Position: refs/heads/master@{#27210}

TBR=yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

Cr-Commit-Position: refs/heads/master@{#27215}
      5977ed02
    • mstarzinger's avatar
      Remove kind field from StackHandler. · 96f79568
      mstarzinger authored 
      This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.

There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.

With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27210}
      96f79568
  57. 10 Mar, 2015 2 commits
  59. 05 Mar, 2015 1 commit
  61. 03 Mar, 2015 1 commit
  63. 01 Oct, 2014 1 commit
  65. 04 Aug, 2014 1 commit
  67. 08 Jul, 2014 1 commit
  69. 03 Jun, 2014 1 commit
  71. 12 May, 2014 1 commit
  73. 29 Apr, 2014 1 commit
  75. 21 Mar, 2014 1 commit