Skip to content

V
V8
Switch branch/tag
  1. 09 Dec, 2016 1 commit
  3. 29 Nov, 2016 2 commits
  5. 23 Nov, 2016 3 commits
    • zhengxing.li's avatar
      X87: [fullcodegen] Remove deprecated generator implementation. · 3eff396a
      zhengxing.li authored 
        port 09255541 (r41135)

  original commit message:
  This removes the deprecated generator support for resumable functions
  from {FullCodeGenerator}. The existing {AstNumbering} heuristic already
  triggers Ignition for most resumable functions, with this change we make
  said heuristic a hard choice and remove the deprecated code. This also
  has the advantage that any suspended {JSGeneratorObject} instance on the
  heap is guaranteed to have code based on a bytecode array.

BUG=

Review-Url: https://codereview.chromium.org/2522653003
Cr-Commit-Position: refs/heads/master@{#41204}
      3eff396a
    • zhengxing.li's avatar
      X87: [x86] Also deal with holey arrays in the Apply builtin. · 7d230e27
      zhengxing.li authored 
        port d4f01b8a (r41108)

  original commit message:
  Add fast paths for holey smi and object arrays to
  Function.prototype.apply, Reflect.apply and Reflect.construct.

BUG=

Review-Url: https://codereview.chromium.org/2519303002
Cr-Commit-Position: refs/heads/master@{#41203}
      7d230e27
    • zhengxing.li's avatar
      X87: [turbofan] Advance bytecode offset after lazy deopt. · d135e764
      zhengxing.li authored 
        port 93c65952 (r40887)

  original commit message:
  This changes {FrameState} nodes modeling "after" states to use bytecode
  offsets pointing to the deoptimizing bytecode. This is in sync with the
  normal execution, as the bytecode offset is advanced after operations
  complete in regular bytecode handlers.

  The change is necessary to ensure lazy deoptimized frames contain an
  accurate bytecode offset while they are on the stack. Such frames can be
  inspected by various stack walks. The continuation builtin will advance
  the bytecode offset upon return.

BUG=

Review-Url: https://codereview.chromium.org/2520203002
Cr-Commit-Position: refs/heads/master@{#41199}
      d135e764
  7. 21 Nov, 2016 1 commit
    • mstarzinger's avatar
      [fullcodegen] Remove deprecated generator implementation. · 09255541
      mstarzinger authored 
      This removes the deprecated generator support for resumable functions
from {FullCodeGenerator}. The existing {AstNumbering} heuristic already
triggers Ignition for most resumable functions, with this change we make
said heuristic a hard choice and remove the deprecated code. This also
has the advantage that any suspended {JSGeneratorObject} instance on the
heap is guaranteed to have code based on a bytecode array.

R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2504223002
Cr-Commit-Position: refs/heads/master@{#41135}
      09255541
  9. 16 Nov, 2016 1 commit
  11. 04 Nov, 2016 1 commit
    • mstarzinger's avatar
      [compiler] Remove --ignition-preserve-bytecode flag. · 01219881
      mstarzinger authored 
      This removes the deprecated flag in question which has been enabled by
default a while ago. All components can by now deal with activations of
a single function being mixed between Ignition and other compilers. The
maintenance overhead to support a mode that clears bytecode is no longer
warranted.

R=rmcilroy@chromium.org
BUG=v8:4280

Review-Url: https://codereview.chromium.org/2475203003
Cr-Commit-Position: refs/heads/master@{#40776}
      01219881
  13. 27 Oct, 2016 1 commit
  15. 24 Oct, 2016 1 commit
    • zhengxing.li's avatar
      X87: [compiler] Mark shared functions for optimization. · ac8318e2
      zhengxing.li authored 
        port 4a31323e (r40506)

  original commit message:
  The current method of marking functions for optimization, which replaces
  the JSFunction's code object with one that triggers optimization, would
  never allow unnamed functions to be optimized. This is an issue for a
  style of programming which heavily relies on passing around closures.

  This patch sets a bit on the SharedFunctionInfo when a JSFunction is
  marked. When another JSFunction referring to the same SharedFunctionInfo
  is lazily compiled, it immediately triggers a non-concurrent optimize.

BUG=

Review-Url: https://codereview.chromium.org/2439393002
Cr-Commit-Position: refs/heads/master@{#40520}
      ac8318e2
  17. 21 Oct, 2016 1 commit
    • leszeks's avatar
      [compiler] Mark shared functions for optimization · 4a31323e
      leszeks authored 
      The current method of marking functions for optimization, which replaces
the JSFunction's code object with one that triggers optimization, would
never allow unnamed functions to be optimized. This is an issue for a
style of programming which heavily relies on passing around closures.

This patch sets a bit on the SharedFunctionInfo when a JSFunction is
marked. When another JSFunction referring to the same SharedFunctionInfo
is lazily compiled, it immediately triggers a non-concurrent optimize.

BUG=v8:5512

Review-Url: https://chromiumcodereview.appspot.com/2437043002
Cr-Commit-Position: refs/heads/master@{#40506}
      4a31323e
  19. 18 Oct, 2016 1 commit
  21. 11 Oct, 2016 1 commit
  23. 07 Oct, 2016 3 commits
  25. 06 Oct, 2016 1 commit
  27. 29 Sep, 2016 1 commit
  29. 18 Sep, 2016 2 commits
    • zhengxing.li's avatar
      X87: [Interpreter] Adds stackcheck in InterpreterPushArgsAndCall/Construct builtins. · 20693493
      zhengxing.li authored 
        port 7f3d15aa(r39470)

  original commit message:
  In ignition, arguments to function calls and function constructors are
  pushed onto the stack before calling the function. It is required to check
  that stack does not overflow when pushing the arguments.

BUG=

Review-Url: https://codereview.chromium.org/2351543002
Cr-Commit-Position: refs/heads/master@{#39491}
      20693493
    • zhengxing.li's avatar
      X87: [turbofan] Collect invocation counts and compute relative call frequencies. · b6acda3a
      zhengxing.li authored 
        port c7d7ca36(r39410)

  original commit message:
  Add a notion of "invocation count" to the baseline compilers, which
  increment a special slot in the TypeFeedbackVector for each invocation
  of a given function (the optimized code doesn't currently collect this
  information).

  Use this invocation count to relativize the call counts on the call
  sites within the function, so that the inlining heuristic has a view
  of relative importance of a call site rather than some absolute numbers
  with unclear meaning for the current function. Also apply the call site
  frequency as a factor to all frequencies in the inlinee by passing this
  to the graph builders so that the importance of a call site in an
  inlinee is relative to the topmost optimized function.

  Note that all functions that neither have literals nor need type
  feedback slots will share a single invocation count cell in the
  canonical empty type feedback vector, so their invocation count is
  meaningless, but that doesn't matter since we only use the invocation
  count to relativize call counts within the function, which we only have
  if we have at least one type feedback vector (the CallIC slot).

  See the design document for additional details on this change:
  https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8

BUG=

Review-Url: https://codereview.chromium.org/2352493002
Cr-Commit-Position: refs/heads/master@{#39490}
      b6acda3a
  31. 15 Sep, 2016 1 commit
  33. 12 Sep, 2016 1 commit
  35. 09 Sep, 2016 1 commit
  37. 04 Sep, 2016 1 commit
  39. 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
  41. 24 Aug, 2016 1 commit
  43. 17 Aug, 2016 1 commit
  45. 12 Aug, 2016 1 commit
    • yangguo's avatar
      [debugger] separate break point info from code instrumentation. · b8c05042
      yangguo authored 
      Previously, we would both instrument the code, and add/remove
BreakPointInfo objects through BreakLocation. This is bad design and
unsuitable for having two different code kinds.

We would now add/remove BreakPointInfo objects, and use that as source
of truth when instrumenting the code. If we have both bytecode and FCG
code, we would simply apply these break points twice to either.

Notable changes:
- Removed many functionality from BreakLocation.
- Instrumentation (patching code for breaks) happens by applying break
  point info onto code.
- Instrumentation (code patching) is done by the BreakIterator. For
  bytecode, it's BytecodeArrayBreakIterator. For FCG code, it's
  CodeBreakIterator.
- Changes to code instrumentation mostly involves clearing current
  instrumentation and then (re-)applying break points.
- DebugInfo can now reference both bytecode and FCG code.

R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5265

Review-Url: https://codereview.chromium.org/2238893002
Cr-Commit-Position: refs/heads/master@{#38596}
      b8c05042
  47. 11 Aug, 2016 1 commit
  49. 09 Aug, 2016 1 commit
  51. 28 Jul, 2016 1 commit
  53. 22 Jul, 2016 1 commit
  55. 20 Jul, 2016 2 commits
  57. 18 Jul, 2016 1 commit
  59. 15 Jul, 2016 1 commit
  61. 14 Jul, 2016 2 commits