Skip to content

V
V8
Switch branch/tag
  1. 20 Jan, 2017 1 commit
  3. 19 Jan, 2017 3 commits
  5. 18 Jan, 2017 2 commits
  7. 17 Jan, 2017 2 commits
  9. 12 Jan, 2017 4 commits
  11. 03 Jan, 2017 1 commit
    • rmcilroy's avatar
      [Ignition] Teach CompileLazy about interpreted functions. · 72c37076
      rmcilroy authored 
      Currently the CompileLazy builtin checks the SFI expliciltly for FCG code. This means
if the SFI has bytecode we have to go through to the runtime to install the
interpreter entry trampoline into the JSFunction object.

Modify the builtin to always put the SFI code object into the JSFunction unless it's
the lazy compile stub on the SFI as well.

BUG=v8:4380

Review-Url: https://codereview.chromium.org/2583693003
Cr-Commit-Position: refs/heads/master@{#42034}
      72c37076
  13. 29 Dec, 2016 1 commit
  15. 22 Dec, 2016 1 commit
  17. 21 Dec, 2016 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root literal arrays in function literals slots · 93df0940
      mvstanton authored 
      Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.

To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
      93df0940
  19. 08 Dec, 2016 2 commits
  21. 07 Dec, 2016 1 commit
  23. 29 Nov, 2016 2 commits
  25. 28 Nov, 2016 1 commit
  27. 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
  29. 10 Nov, 2016 1 commit
    • mstarzinger's avatar
      [turbofan] Advance bytecode offset after lazy deopt. · 93c65952
      mstarzinger authored 
      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.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-660379
BUG=chromium:660379

Review-Url: https://codereview.chromium.org/2487173002
Cr-Commit-Position: refs/heads/master@{#40887}
      93c65952
  31. 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
  33. 27 Oct, 2016 1 commit
  35. 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
  37. 18 Oct, 2016 1 commit
  39. 07 Oct, 2016 6 commits
  41. 06 Oct, 2016 1 commit
  43. 05 Oct, 2016 1 commit
  45. 29 Sep, 2016 1 commit
  47. 16 Sep, 2016 1 commit
  49. 15 Sep, 2016 1 commit
  51. 14 Sep, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Collect invocation counts and compute relative call frequencies. · c7d7ca36
      bmeurer authored 
      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=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
      c7d7ca36