1. 06 Jan, 2022 1 commit
  2. 05 Jan, 2022 17 commits
  3. 04 Jan, 2022 19 commits
  4. 03 Jan, 2022 3 commits
    • Anton Bershanskiy's avatar
      Fix gen-keywords-gen-h.py · f3214885
      Anton Bershanskiy authored
      Commit 84f3877c moved IsInRange to
      base::IsInRange and updated src/parsing/keywords-gen.h, but did not
      update tools/gen-keywords-gen-h.py.
      
      Bug: v8:12507
      Change-Id: I914ba73feac3bac6fd5d08d14d17149faf6c5c76
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3356200Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78467}
      f3214885
    • Benedikt Meurer's avatar
      [debug] Lazily lookup source positions for StackFrameInfo. · 2ffc79b7
      Benedikt Meurer authored
      This changes the StackFrameInfo to either hold on to a pair of
      
        (Script,source position)
      
      or a pair of
      
        (SharedFunctioInfo,bytecode offset)
      
      similar to what we do for MessageLocation. The idea here is to defer the
      costly bytecode offset to source position lookup until really needed,
      and in particular, avoid the costly lookup during stack trace capturing.
      
      On the `standalone.js` benchmark in crbug.com/1283162#c1, this reduces
      overall average execution time by roughly 25%, and the performance is
      almost back to where it was before crrev.com/c/3302794 (being only 12%
      slower than before on the `standalone.js` test case).
      
      Note that due to unrelated limitations we cannot encode -1 as bytecode
      offset in the flags field of the StackFrameInfo, and so we treat this
      case specially (happens when stack trace capturing is triggered in the
      function entry sequence) and just eagerly resolve it to the source
      position.
      
      Bug: chromium:1278650, chromium:1283162, chromium:1280803
      Bug: chromium:1280818, chromium:1280831, chromium:1280832
      Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
      Change-Id: If7cf62fce48d32c0f188895d1f8c9eee51b9e70d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359633Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78466}
      2ffc79b7
    • Samuel Groß's avatar
      [platform] Use MADV_DONTNEED in OS::DiscardSystemPages on Linux · a457ee76
      Samuel Groß authored
      This is in line with PartitionAlloc's DiscardSystemPagesInternal.
      
      When the sandbox is enabled, OS::DiscardSystemPages is used instead of
      PA's version. As such, these two implementations should ideally be
      mostly identical. Using MADV_FREE instead of MADV_DONTNEED as was
      previously done appears to cause some memory regressions.
      
      Bug: chromium:1276887
      Change-Id: Ied92b106e9894d428e599801d753ab4c8cffd874
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364090Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78465}
      a457ee76