1. 16 Nov, 2018 1 commit
  2. 29 Oct, 2018 1 commit
  3. 21 Sep, 2018 1 commit
  4. 03 Aug, 2018 1 commit
  5. 03 Jul, 2018 1 commit
  6. 14 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored
      This is a reland of 0909dbe3.
      Added missing V8_EXPORT_PRIVATE to AndroidLogStream.
      
      TBR=mstarzinger@chromium.org
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      >
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      >
      > R=mstarzinger@chromium.org
      >
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      Bug: v8:7820
      Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
      Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257
    • Michael Achenbach's avatar
      Revert "Introduce StdoutStream which prints to Android log or stdout" · d2e1620c
      Michael Achenbach authored
      This reverts commit 0909dbe3.
      
      Reason for revert: Blocks roll:
      https://chromium-review.googlesource.com/c/chromium/src/+/1099143
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      > 
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org
      
      Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7820
      Reviewed-on: https://chromium-review.googlesource.com/1100635Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53725}
      d2e1620c
  7. 13 Jun, 2018 1 commit
  8. 06 Jun, 2018 1 commit
  9. 31 May, 2018 1 commit
  10. 16 Apr, 2018 1 commit
  11. 22 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Introduce a dedicated FeedbackCell. · aff1f378
      Benedikt Meurer authored
      This is preparatory cleanup work for eventually tracking the functions
      (rather than concrete closures) in the CALL_IC, also for builtins like
      the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
      adds a new FeedbackCell type, which is used by JSFunctions consistently
      now to reference the feedback vector (or undefined if not the function
      is not compiled yet or is a native/asm.js function).
      
      This also changes the calling convention for FastNewClosure builtin and
      the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
      instead of the parent FeedbackVector and the slot index. In addition we
      eliminate the now unused %InterpreterNewClosure runtime function.
      
      Bug: v8:2206, v8:7253, v8:7310
      Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
      Reviewed-on: https://chromium-review.googlesource.com/928403
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51474}
      aff1f378
  12. 14 Nov, 2017 1 commit
    • Jakob Gruber's avatar
      Revert "Revert lazy bytecode handler support" · e0400694
      Jakob Gruber authored
      This reverts commit 9e4543a2.
      
      Reason for revert: Culprit CL was found, let's reland this.
      
      Original change's description:
      > Revert lazy bytecode handler support
      >
      > Speculative revert due to canary crashes. I'll begin relanding these
      > one-by-one next week.
      >
      > This bundles two reverts:
      >
      > Revert "[snapshot] Lazy-deserialize bytecode handlers"
      > This reverts commit b4587369.
      >
      > Revert "[interpreter] Remove mechanism for bytecode handler reuse"
      > This reverts commit 07fc87a2.
      >
      > TBR: rmcilroy@chromium.org,mlippautz@chromium.org,yangguo@chromium.org
      > Bug: chromium:783708
      > Change-Id: I6f8314b9eeafd9412a1c69843bc242e7da240eee
      > Reviewed-on: https://chromium-review.googlesource.com/763428
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49294}
      
      TBR=rmcilroy@chromium.org,mlippautz@chromium.org,yangguo@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:783708
      Change-Id: I6c9274ddf0d0832ecce32baacc4f6a1388f56ac4
      Reviewed-on: https://chromium-review.googlesource.com/768749
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49362}
      e0400694
  13. 10 Nov, 2017 1 commit
    • jgruber's avatar
      Revert lazy bytecode handler support · 9e4543a2
      jgruber authored
      Speculative revert due to canary crashes. I'll begin relanding these
      one-by-one next week.
      
      This bundles two reverts:
      
      Revert "[snapshot] Lazy-deserialize bytecode handlers"
      This reverts commit b4587369.
      
      Revert "[interpreter] Remove mechanism for bytecode handler reuse"
      This reverts commit 07fc87a2.
      
      TBR: rmcilroy@chromium.org,mlippautz@chromium.org,yangguo@chromium.org
      Bug: chromium:783708
      Change-Id: I6f8314b9eeafd9412a1c69843bc242e7da240eee
      Reviewed-on: https://chromium-review.googlesource.com/763428
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49294}
      9e4543a2
  14. 08 Nov, 2017 1 commit
  15. 26 Oct, 2017 1 commit
  16. 25 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored
      This change adapts the Call bytecode handlers such that they don't require
      a stack frame. It does this by modifying the call bytecode handler to
      tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
      callee function will return to the InterpreterEntryTrampoline when it returns
      (since this is the return address on the interpreter frame), which is
      adapted to dispatch to the next bytecode handler. The return bytecode
      handler is modified to tail-call a new InterpreterExitTramoline instead
      of returning to the InterpreterEntryTrampoline.
      
      Overall this significanlty reduces the amount of stack space required for
      interpreter frames, increasing the maximum depth of recursive calls from
      around 6000 to around 12,500 on x64.
      
      BUG=chromium:753705
      
      Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
      Reviewed-on: https://chromium-review.googlesource.com/634364
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140
  17. 03 Aug, 2017 2 commits
  18. 19 Jul, 2017 1 commit
  19. 07 Jun, 2017 1 commit
  20. 22 May, 2017 1 commit
  21. 16 May, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Change --trace-ignition to a runtime flag · 4becbe34
      Leszek Swirski authored
      Generate the code (extra runtime calls) for --trace-ignition support at
      compile time, based on a #define (similar to TRACE_MAPS). Then check for
      --trace-ignition at run-time when deciding whether to actually print
      anything. This should make --trace-ignition less painful to use.
      
      Note that --trace-igition is disabled by default, even on debug builds.
      It has to be enabled with the gn arg "v8_enable_trace_ignition=true"
      
      As a drive-by, TRACE_MAPS is renamed to V8_TRACE_MAPS, for consistency,
      and SFI unique index (needed both by --trace-ignition and --trace-maps)
      is cleaned up to be behind another #define.
      
      Change-Id: I8dd0c62d0e6b7ee9c75541d45eb729dc03acbee9
      Reviewed-on: https://chromium-review.googlesource.com/506203
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45346}
      4becbe34
  22. 08 Feb, 2017 1 commit
    • mvstanton's avatar
      [FeedbackVector] Clarify the way the feedback vector is installed. · a1bba7fe
      mvstanton authored
      Installing a feedback vector in a closure is a multi-step process.
      The closure actually points to a Cell that points to a feedback
      vector or undefined if we haven't created one yet.
      This happens because we often create closures before we've compiled
      the code.
      
      JSFunction::EnsureLiterals is the bottleneck in our system that
      creates a feedback vector if necessary. The predicates it used to
      determine what to do were arcane. This CL allows it to think it
      terms of state, and clarifies the reading of that useful
      bottleneck.
      
      I also did a few renamings in parts of the code that referred
      to a "literals array," which we don't have any more.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2681773004
      Cr-Commit-Position: refs/heads/master@{#43035}
      a1bba7fe
  23. 07 Feb, 2017 2 commits
  24. 06 Feb, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root feedback vectors at function literal site. · aea3ce3d
      mvstanton authored
      TypeFeedbackVectors are strongly rooted by a closure. However, in modern
      JavaScript closures are created and abandoned more freely. An important
      closure may not be present in the root-set at time of garbage collection,
      even though we've cached optimized code and use it regularly. For
      example, consider leaf functions in an event dispatching system. They may
      well be "hot," but tragically non-present when we collect the heap.
      
      Until now, we've relied on a weak root to cache the feedback vector in
      this case. Since there is no way to signal intent or relative importance,
      this weak root is as susceptible to clearing as any other weak root at
      garbage collection time.
      
      Meanwhile, the feedback vector has become more important. All of our
      ICs store their data there. Literal and regex boilerplates are stored there.
      If we lose the vector, then we not only lose optimized code built from
      it, we also lose the very feedback which allowed us to create that optimized
      code. Therefore it's vital to express that dependency through the root
      set.
      
      This CL does this by creating a strong link to a feedback
      vector at the instantiation site of the function closure.
      This instantiation site is in the code and feedback vector
      of the outer closure.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2674593003
      Cr-Commit-Position: refs/heads/master@{#42953}
      aea3ce3d
  25. 19 Jan, 2017 3 commits
  26. 12 Jan, 2017 3 commits
  27. 09 Jan, 2017 1 commit
  28. 22 Dec, 2016 1 commit
  29. 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
  30. 16 Nov, 2016 1 commit
  31. 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
  32. 15 Jul, 2016 1 commit
  33. 14 Jul, 2016 1 commit