1. 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
  2. 29 Dec, 2016 1 commit
  3. 22 Dec, 2016 1 commit
  4. 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
  5. 08 Dec, 2016 2 commits
  6. 07 Dec, 2016 1 commit
  7. 29 Nov, 2016 2 commits
  8. 28 Nov, 2016 1 commit
  9. 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
  10. 11 Nov, 2016 3 commits
  11. 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
  12. 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
  14. 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
  15. 18 Oct, 2016 1 commit
  16. 07 Oct, 2016 6 commits
  17. 06 Oct, 2016 1 commit
  18. 29 Sep, 2016 1 commit
  19. 16 Sep, 2016 1 commit
  20. 15 Sep, 2016 1 commit
  21. 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
  22. 12 Sep, 2016 1 commit
  23. 08 Sep, 2016 1 commit
  24. 02 Sep, 2016 1 commit
  25. 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
  26. 19 Aug, 2016 1 commit
  27. 17 Aug, 2016 1 commit
  28. 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
  29. 11 Aug, 2016 1 commit
  30. 09 Aug, 2016 1 commit
  31. 05 Aug, 2016 1 commit