1. 09 Jun, 2022 1 commit
  2. 29 Apr, 2022 1 commit
    • Simon Zünd's avatar
      [debug] Implement 'PrepareRestartFrame' · f96994ba
      Simon Zünd authored
      Doc: https://bit.ly/revive-restart-frame
      
      This CL adds the V8 debugger part of the restart frame logic as well
      as some bits for the inspector.
      
      The CL is centered around two key pieces: When the user requests a
      restart, we stash the stack frame ID (aka the stack pointer) and
      optionally the inlined frame index for optimized frames, and then
      continue execution. Once execution bubbles back into JS land,
      we throw a termination exception when a frame restart was requested.
      
      Note that the CL doesn't hook up the logic yet to CDP and the CL
      also does not the actual handling of the termination exception
      in the unwinder.
      
      R=bmeurer@chromium.org, kimanh@chromium.org
      
      Bug: chromium:1303521
      Change-Id: I12cfb408c66072dd19f8180e530f84c987d1374d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3613383Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80272}
      f96994ba
  3. 22 Feb, 2022 1 commit
  4. 11 Feb, 2022 1 commit
  5. 08 Feb, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Implement stepping out of async functions in the debugger. · 536e96cc
      Benedikt Meurer authored
      Previously the inspector was trying to handle step-out for async
      functions by annotating the async stacks, but this was merely a
      hack and didn't work reliably
      
      (a) when the async caller that is `await`ing the result of the
          callee was still in the synchronous part (because then there
          was no async task yet in the inspector), or
      (b) not at all when the async stack tracking wasn't enabled or the
          maximum async stack depth was too small.
      
      This CL replaces that hack with a pragmatic solution inside the
      V8 debugger, where upon `await` we memorize the async function
      object of the caller on the outer promise of the callee, and when
      stepping out of the callee we check whether the returned promise
      has a memorized async function object and if so, we schedule that
      to resume.
      
      This CL thereby effectively reverts https://crrev.com/c/1054618
      and replaces it with a V8 debug solution, and thereby further
      reduces the (memory) overhead of an AsyncStackTrace.
      
      Fixed: chromium:1246867
      Bug: v8:6161, v8:7753, chromium:1277451, chromium:1280519
      Change-Id: I6aa79e90f49d204f66bfd37e7a328c7fb8d635b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439865Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78990}
      536e96cc
  6. 04 Feb, 2022 1 commit
  7. 01 Feb, 2022 2 commits
  8. 13 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Simplify async function instrumentation. · 41f0c0ba
      Benedikt Meurer authored
      This unifies and simplifies the way we instrument async functions for
      the purpose of async stack traces and async stepping. It does so while
      retaining the observable behavior on the inspector level (for now).
      
      Previously we'd mark the implicit promise of the async function object
      with the async task ID, and whenever we awaited, we'd copy the async
      task ID to the throwaway promise that is created by the `await`. This
      however made things unnecessarily interesting in the following regards:
      
      1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the
      `AsyncFunctionFinished` events, coming from the throwaway promises,
      while the implicit promise is "done". This is especially confusing
      with rejection propagation and requires very complex stepping logic
      for async functions (after this CL it'll be possible to unify and
      simplify the stepping logic).
      2. We have to thread through the "can suspend" information from the
      Parser all the way through AsyncFunctionReject/AsyncFunctionResolve
      to the async function instrumentation to decide whether to cancel the
      pending task when the async function finishes.
      
      This CL changes the instrumentation to only happen (non recurringly) for
      the throwaway promises allocated upon `await`. This solves both problems
      mentioned above, and works because upon the first `await` the stack
      captured for the throwaway promise will include the synchronous part as
      expected, while upon later `await`s the synchronous part will be empty
      and the asynchronous part will be the stack captured for the previous
      throwaway promise (and the V8Debugger automatically short circuits
      stacks with empty synchronous part).
      
      Bug: chromium:1280519, chromium:1277451, chromium:1246867
      Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78599}
      41f0c0ba
  9. 04 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [inspector] Fix `Runtime.setMaxCallStackSizeToCapture`. · 8f8d2fe4
      Benedikt Meurer authored
      This change fixes the implementation of the previously introduced API
      `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply
      (consistently) to stack traces captured by V8 when exceptions are
      thrown. It does so in a fully backwards compatible manner.
      
      This change thus makes the previous fix for catapult (which landed in
      http://crrev.com/c/3347789) effective, and therefore ensures that real
      world performance benchmarks aren't affected by the use of the `Runtime`
      domain in the catapult test framework.
      
      Note this is basically a reland of crrev.com/c/3361839, but without
      touching the stack traces for console messages (which led to the
      regressions in crbug/1283516, crbug/1283523, etc.).
      
      Fixed: chromium:1280831
      Bug: chromium:1283162, chromium:1278650, chromium:1258599
      Bug: chromium:1280803, chromium:1280832, chromium:1280818
      Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
      Change-Id: I3dcec7b75d76ca267fac8bd6fcb2cda60d5e60dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364086Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78479}
      8f8d2fe4
  10. 03 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      Revert "[inspector] Fix `Runtime.setMaxCallStackSizeToCapture`." · c51b582d
      Benedikt Meurer authored
      This reverts commit 34f73cc7.
      
      Reason for revert: Performance regressions throughout a lot of
      system health and browsing benchmarks.
      
      Original change's description:
      > [inspector] Fix `Runtime.setMaxCallStackSizeToCapture`.
      >
      > This change fixes the implementation of the previously introduced API
      > `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply
      > (consistently) to stack traces captured by V8 when exceptions are
      > thrown. It does so in a fully backwards compatible manner.
      >
      > This change thus makes the previous fix for catapult (which landed in
      > http://crrev.com/c/3347789) effective, and therefore ensures that real
      > world performance benchmarks aren't affected by the use of the `Runtime`
      > domain in the catapult test framework.
      >
      > Bug: chromium:1283162, chromium:1278650, chromium:1258599
      > Bug: chromium:1280803, chromium:1280832, chromium:1280818
      > Fixed: chromium:1280831
      > Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
      > Change-Id: I4ec951a858317fa49096cd4023deb0104d92c9c9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361839
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78458}
      
      Bug: chromium:1283162, chromium:1278650, chromium:1258599
      Bug: chromium:1280803, chromium:1280832, chromium:1280818
      Bug: chromium:1280831
      Change-Id: Id1efaffa2f7f08c47f833f68b8a297494edee21e
      Fixed: chromium:1283751, chromium:1283749, chromium:1283746
      Fixed: chromium:1283729, chromium:1283700, chromium:1283700
      Fixed: chromium:1283691, chromium:1283687, chromium:1283678
      Fixed: chromium:1283677, chromium:1283676, chromium:1283675
      Fixed: chromium:1283674, chromium:1283618, chromium:1283536
      Fixed: chromium:1283523, chromium:1283516
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364078
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78462}
      c51b582d
  11. 31 Dec, 2021 1 commit
  12. 30 Dec, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Introduce v8::StackFrame::GetLocation() API. · ed7b6640
      Benedikt Meurer authored
      This introduces a new `GetLocation()` method for `v8::StackFrame`s,
      which returns both line and column number at the same time (using the
      existing `v8::Location` class). Since `v8::StackFrame` instances store
      only the source position (per https://bit.ly/v8-stack-frame), we
      currently need to look up the source position in the Script's line table
      twice, once when we request the line number, and another time when we
      request the column number.
      
      With `GetLocation()` we perform only a single lookup in the Script's
      line table and return both line and column number at the same time. This
      cuts roughly 8% of the average execution time from the `standalone.js`
      benchmark mentioned in crbug.com/1280519.
      
      Bug: chromium:1280519, chromium:1278650, chromium:1069425
      Bug: chromium:1077657, chromium:1283162
      Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
      Change-Id: Ia3a0502990b6230363112a358b59875283399404
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359628Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78452}
      ed7b6640
  13. 08 Dec, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Consistent frame function name in V8 Inspector and API. · 54584461
      Benedikt Meurer authored
      On the way to a cheaper and more scalable stack frame representation
      for the inspector (crbug/1258599), this removes the need to expose
      both what was called "function name" and what was called "function
      debug name" on a v8::StackFrame instance.
      
      The reason to having a distinction between that the V8 API exposes
      and what the inspector exposes as frame function name is that after
      the initial refactoring around v8::internal::StackFrameInfo, some
      wasm cctests would still dig into the implementation details and
      insist on seeing the "function name" rather than the "function
      debug name". This CL now addresses that detail in the wasm cctests
      and going forward unifies the function names used by the inspector
      and the V8 API (which is not only needed for internal consistency
      and reduced storage requirements in the future, but also because
      Blink for example uses v8 API and v8_inspector API interchangeably
      and assumes that they agree, even though at this point Blink
      luckily wasn't paying attention to the function name):
      
      - The so-called "detailed stack trace", which is produced for the
        inspector and exposed by the v8 API, always yields the "function
        debug name" (which for example in case of wasm will be a WAT
        compatible name),
      - while the so-called "simple stack trace", which is what is used
        to implement the CallSite API and underlies Error.stack continues
        to stick to the "function name" which in case of wasm is not
        WAT compatible).
      
      Bug: chromium:1258599
      Change-Id: Ib15d038f3ec893703d0f7b03f6e7573a38e82b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312274Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78283}
      54584461
  14. 07 Dec, 2021 2 commits
  15. 02 Dec, 2021 1 commit
  16. 29 Nov, 2021 2 commits
  17. 11 Nov, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Cache StackFrames by script, line and column number. · e60dc99e
      Benedikt Meurer authored
      This introduces a stack frame cache on the V8Debugger level, which
      de-duplicates StackFrame instances based on their scriptId, line and
      column number.
      
      This greatly reduces the memory pressure when debugging huge Web
      applications that have a lot of async activity (and potentially
      have scripts with huge URLs). This is guided by the observation
      that even in huge applications, there are only a very limited
      number of call sites that initiate async activity and hence we
      only have a limited number of distinct StackFrames to worry
      about (despite having to maintain a large number of async stack
      traces overall).
      
      As a nice side effect, this CL also greatly reduces the negative
      performance impact of collecting async stack traces in these
      huge applications.
      
      Generally speaking this is mostly duct tape however, and we might
      want to follow up with changes to make capturing (and storing)
      stack frames even cheaper.
      
      Fixed: chromium:1268436
      Change-Id: Ib212b3c97dce2bb7ca47d5875d45cf20b9b97afe
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272577
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77835}
      e60dc99e
  18. 13 Oct, 2021 1 commit
  19. 12 Oct, 2021 1 commit
    • Kim-Anh Tran's avatar
      [debug] Capture more cases for instrumentation breakpoints · 0c3fdff2
      Kim-Anh Tran authored
      The previous implementation would not explicitly send
      `Debugger.paused` events for instrumentation breakpoints
      if they were to overlap with breaks due to:
      * regular breakpoints
      * OOM
      * exceptions
      * asserts
      
      This CL is a step towards making sure that a separate
      `Debugger.paused` event is always sent for an instrumentation
      breakpoint. In some cases where we have overlapping reasons
      but only know of one, the 'instrumentation' reason,
      we still just send out one paused event with the reason
      being `instrumentation`.
      
      Drive-by: send instrumentation notification to all sessions,
      remember which breakpoints are instrumentation breakpoints
      
      Bug: chromium:1229541, chromium:1133307
      Change-Id: Ie15438f78b8b81a89c64fa291ce7ecc36ebb2182
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211892Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77333}
      0c3fdff2
  20. 08 Oct, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Reduce upper bound for async stack traces. · 08aa49eb
      Benedikt Meurer authored
      The V8Debugger maintains a list of async stack traces that were captured
      so far, two mappings pointing weakly to async stack traces in this (one
      mapping for tasks and one mapping for stored async stack traces). The
      V8Debugger regularly prunes the list (and cleans up the stale weak
      pointers afterwards) by going through the list in insertion order and
      removing items until the number is below half the limit of 128k entries.
      
      This approach wastes a lot of memory, since the list grows very big
      before this manual collection starts, and it doesn't pay any attention
      to whether the stack traces are still in active use or not. Also the
      limit of 128k seems incredibly high (and arbitrary).
      
      This leads to crashes observed in applications with lots of async task
      activity (i.e. huge Angular applications) as soon as the debugger is
      attached.
      
      This CL performs a quickfix by reducing the limit for async stack traces
      to a more reasonable number of 8k. We will need to follow up with a
      proper fix that ensures that we only hold on strongly to async stack
      traces that are still in need.
      
      Also-By: jarin@chromium.org
      Fixed: chromium:1258000
      Bug: chromium:1257637, chromium:1254279, chromium:1203218
      Change-Id: I2c482a688df4c6df575a0045d443db89d89b3d73
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211709
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77301}
      08aa49eb
  21. 30 Sep, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Align async task frame reporting for `await`. · d6c01059
      Benedikt Meurer authored
      The V8 Inspector was sending an additional frame as part of async stack
      traces for async functions, which pointed to the first executed `await`
      in the async function. This is leaking an implementation detail of how
      (and more precisely when) the inspector decides to collect this stack
      trace. From the users perspective the async part of the stack trace is
      supposed to capture what happened _prior to the task_ - meaning in case
      of async functions: What lead to the execution of the async function.
      This is reflected by the fact that the DevTools front-end (and the V8
      Inspector itself) performs post-processing on these async call stacks,
      removing the misleading top frame from it. But this post-processing is
      not applied consistently to all async stack traces (i.e. the Console
      message stack traces don't get this), and potentially also not applied
      consistently across consumers of the Chromium debugger backend.
      
      Instead the V8 Inspector now removes the top frame itself and thus
      reports `await` consistently with how other async tasks are reported to
      debugger front-ends.
      
      Note: This preserves backwards compatibility with old versions of
      devtools-frontend, which do post-processing (for the Call Stack) only on
      async stack traces marked with "async function", while we now mark these
      async stack traces with "await" instead (aligned with what the front-end
      is using as user visibile string anyways in the Call Stack section, and
      this matching will be updated in a separate follow up CL to look for
      "await" instead of "async function").
      
      Before: https://imgur.com/kIrWcIc.png
      After: https://imgur.com/HvZGqiP
      Fixed: chromium:1254259
      Bug: chromium:1229662
      Change-Id: I57ce051a28892177b6b96221f083ae957f967e52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193535
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77157}
      d6c01059
  22. 27 Sep, 2021 1 commit
  23. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored
      This is a reland of d1b27019
      
      Fixes include:
      Adding missing file to bazel build
      Forward-declaring classing before friend-classing them to fix win/gcc
      Add missing v8-isolate.h include for vtune builds
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
      Bug: v8:11965
      Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  24. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored
      This reverts commit d1b27019.
      
      Reason for revert: Broke vtune build, tsan build and possibly others
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Bug: v8:11965
      Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored
      This moves every single class/function out of include/v8.h into a
      separate header in include/, which v8.h then includes so that
      externally nothing appears to have changed.
      
      Every include of v8.h from inside v8 has been changed to a more
      fine-grained include.
      
      Previously inline functions defined at the bottom of v8.h would call
      private non-inline functions in the V8 class. Since that class is now
      in v8-initialization.h and is rarely included (as that would create
      dependency cycles), this is not possible and so those methods have been
      moved out of the V8 class into the namespace v8::api_internal.
      
      None of the previous files in include/ now #include v8.h, which means
      if embedders were relying on this transitive dependency then it will
      give compile failures.
      
      v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      that Chrome continue to compile but that change will be reverted once
      those transitive #includes in chrome are changed to include it directly.
      
      Full design:
      https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      
      Bug: v8:11965
      Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  25. 16 Aug, 2021 1 commit
    • Santiago Aboy Solanes's avatar
      Revert "Reland "[debugger] Try to trigger pause-on-oom flakes with an extra printf"" · c357f447
      Santiago Aboy Solanes authored
      This reverts commit a4a152ec.
      
      Reason for revert: We haven't seen the flakes in a while, we can re-enable functionality
      
      Original change's description:
      > Reland "[debugger] Try to trigger pause-on-oom flakes with an extra printf"
      >
      > This is a reland of 8f7e9158
      >
      > Original change's description:
      > > [debugger] Try to trigger pause-on-oom flakes with an extra printf
      > >
      > > We have an issue that we can't repro locally. Enable back the
      > > pause-on-oom tests with an extra printf with DEBUG. We will be able to
      > > better assess the failures when they appear on the bot.
      > >
      > > Bug: v8:10876
      > > Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70558}
      >
      > Bug: v8:10876
      > Change-Id: Ice31c9455830da320ab057293c341f69e1f0c510
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484799
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70643}
      
      Bug: v8:10876
      Change-Id: I901d31e1e92bfef0b2917ea611354618e5cda585
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071404Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76302}
      c357f447
  26. 23 Jul, 2021 1 commit
  27. 01 Jul, 2021 1 commit
  28. 01 Jun, 2021 1 commit
  29. 27 May, 2021 1 commit
  30. 30 Apr, 2021 1 commit
  31. 02 Mar, 2021 1 commit
  32. 16 Feb, 2021 1 commit
  33. 24 Dec, 2020 1 commit
  34. 23 Dec, 2020 1 commit
  35. 22 Dec, 2020 1 commit
  36. 28 Nov, 2020 1 commit