1. 17 Feb, 2021 3 commits
  2. 16 Feb, 2021 1 commit
  3. 15 Feb, 2021 2 commits
  4. 12 Feb, 2021 10 commits
  5. 11 Feb, 2021 3 commits
    • Santiago Aboy Solanes's avatar
      [objects] Delete double field unboxing · 42409a2e
      Santiago Aboy Solanes authored
      Reasons:
       * We disabled it more than a year ago for all configs
       * Not easy to re-enable
       * Not compatible with pointer compression as-is
       * Not compatible with concurrent TP/TF as-is
       * No concrete plans to re-enable it
      
      Also remove Map's layout_descriptor since it was only used for double
      field unboxing.
      
      Bug: v8:11422
      Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72671}
      42409a2e
    • Pierre Langlois's avatar
      [tools] Fix v8gen.py list command. · 4c5ea143
      Pierre Langlois authored
      Bug: v8:11361
      Change-Id: Ie36b612907fab01c269567e901494d2c7ea01b6d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689192Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#72654}
      4c5ea143
    • Benedikt Meurer's avatar
      [stack-traces] Remove StackFrameInfo. · 11b6f176
      Benedikt Meurer authored
      For a long time, V8 had two distinct ways to capture and store a stack
      trace, one where we'd just collect and symbolize the information for the
      v8::StackTrace API (script id, name, line and colum information mostly),
      and one where V8 would also memorize the closures, receivers, and
      optionally the parameters of the stack frame, which we use for
      Error.stack and the non-standard CallSite APIs. Those two were often out
      of sync and suffered from various different issues. Eventually they were
      refactored into a single captureStackTrace() bottleneck that would
      produce a FrameArray.
      
      This CL is a logical continuation of the refactorings. It repairs a
      regression where we'd compute the method name (as part of the
      cached StackFrameInfo) even if we don't need them (as is the case for
      the inspector and any other use of the v8::StackTrace API).
      
      Everytime a method was invoked on StackTraceFrame, it'd call into
      StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo
      like this:
      
        1. Create a FrameArrayIterator and point it to the FrameArray at the
           index stored in the StackTraceFrame.
        2. Invoke FrameArrayIterator::Frame(), which copies the information
           from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame
           or WasmStackFrame C++ object, and use the StackFrameBase virtual
           methods to transfer all information to a newly created
           StackFrameInfo object.
        3. Kill the link to the FrameArray and put a link to the
           StackFrameInfo object into the StackTraceFrame.
      
      This caching turned out to be extremely costly, since beyond other
      things, it'd always invoke JSStackFrame::GetMethodName(), which is
      extremely costly (the execution time is linear in the number of
      properties on the receiver and it's prototype chain). The cost was so
      high that several work-arounds had been added, which would avoid
      triggering the eager construction of the StackFrameInfo object (i.e.
      https://crrev.com/c/2080663, https://crrev.com/c/2550504 or
      https://crrev.com/c/2261736, but also https://crrev.com/c/1688927).
      
      This CL removes the StackFrameInfo caching completely, since neither the
      inspector nor Error.stack benefit from the caching at all. It's only the
      first part in a series of refactorings that will significantly reduce
      the complexity and overhead of the stack trace collection.
      
      Doc: https://bit.ly/2wkbuIy
      Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742
      Bug: chromium:1127391, chromium:1098530, chromium:981541
      Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72647}
      11b6f176
  6. 10 Feb, 2021 1 commit
    • Georg Neis's avatar
      Revert "[compiler] Directly read PropertyCells" · 87df0b7e
      Georg Neis authored
      This reverts commit 42cd9eb7.
      
      Reason for revert: Clusterfuzz issues, e.g.
      https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      
      Original change's description:
      > [compiler] Directly read PropertyCells
      >
      > Main changes:
      >
      > - Introduce a new broker data kind kBackgroundSerialized for objects
      >   that can be serialized in the background (when direct reads are on).
      >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > - Make PropertyCell use that new kind.
      > - Introduce a bottleneck in runtime code for changes to PropertyCells
      >   and make sure that a certain protocol is followed that allows
      >   concurrent reads from the background thread.
      > - Improve interface of PropertyCell in various ways.
      >
      > Bug: v8:7790
      > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72586}
      
      TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      
      Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      Bug: v8:7790
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72619}
      87df0b7e
  7. 09 Feb, 2021 4 commits
  8. 08 Feb, 2021 2 commits
    • Camillo Bruni's avatar
      [tools] Improve callstats.html · 2dc8934d
      Camillo Bruni authored
      CSV Support:
      - Add import merged CSV from results.html
      - Aggregate multiple runs and calculate stddev on them
      
      Charts:
      - Defer rendering charts for responsive UI
      - Clean up chart rendering in general
      - Sort charts based on raw chart data for speedups
      - Show chart annotations
      - Add chart total, displaying the total value for the currently
        selected categories
      - Fix sorting by chart total
      - Add average row for all charts
      
      Change-Id: I1e542f319172ecf158dcb44f8da7ad6e81aafe41
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675934Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72562}
      2dc8934d
    • Clemens Backes's avatar
      [wasm][memory64] Update spec tests · c5b9cae0
      Clemens Backes authored
      Update the wasm spec tests to include the memory64 proposal. Some tests
      are failing currently because of broken spec tests or missing v8
      support. This will be addressed in follow-up CLs.
      
      R=ahaas@chromium.org
      CC=zhin@chromium.org
      
      Bug: v8:11401
      Change-Id: I1a8f75e70f9d0828ad32c960c113f5e4c0d1a44b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679683
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72561}
      c5b9cae0
  9. 04 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [literals] Add a dedicated regexp boilerplate type · e79b841b
      Jakob Gruber authored
      ... and mark it as never-serialized wrt turbofan serialization.
      
      Until this CL, the JSRegExp type was used as both for plain
      user-visible regexp objects, and for internal regexp boilerplate
      descriptions. Boilerplates are special: they are never exposed to the
      user, they are only referenced from the feedback vector, they are
      immutable.
      
      To clarify this distinction, this CL introduces a dedicated struct
      type RegExpBoilerplateDescription to hold the regexp boilerplate
      description.
      
      This makes Turbofan serialization simpler: boilerplates can be
      accessed through direct reads since they are immutable. TF has no
      special requirements on JSRegExp objects (it never reads into these
      objects) and thus serializing only the references as a JSObjectRef is
      fine.
      
      Bug: v8:7790
      Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72522}
      e79b841b
  10. 03 Feb, 2021 1 commit
  11. 02 Feb, 2021 1 commit
    • Leszek Swirski's avatar
      [arm64/sim] Add a 'sim' gdb command · 1f72df06
      Leszek Swirski authored
      Extract out the command processing from Simulator::Debug(), and expose
      it to gdb as a new 'sim' command. Example usage:
      
          (gdb) sim p x15
          (gdb) sim stack
      
      The sim command will execute that one command, and will return to gdb.
      
      For a list of all commands, you can call
      
          (gdb) sim help
      
      Note that sim won't resume simulator execution until gdb continues
      execution; for example, `sim next` will set a breakpoint on the next
      instruction, and will return to gdb. The user then has to continue
      execution in gdb, at which point the simulator will break. The user can
      then re-enter gdb with the gdb command. This will look like this:
      
          (gdb) sim next
          (gdb) continue
          ...
          sim> gdb
          (gdb) ...
      
      Change-Id: I678e71e2642d8427950b5f7ed65890ceae69e18d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664448
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72479}
      1f72df06
  12. 01 Feb, 2021 3 commits
  13. 29 Jan, 2021 2 commits
  14. 28 Jan, 2021 6 commits