1. 24 Mar, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Hold on to promises weakly from the debugger's promise stack. · 3eb6b7ac
      Benedikt Meurer authored
      The debugger maintains a stack of promises used for catch prediction
      with promise builtins and async functions. Previously this stack would
      hold on to the individual promises strongly, and subtle bugs that lead
      to not properly cleaning up the stack in some corner cases would often
      lead to significant memory issues (e.g. leaking whole iframes).
      
      This refactors the PromiseOnStack to be
      
        (a) on the V8 heap, rather than allocating C++ structs with global
            handles pointing to the promises, and
        (b) hold on to the promises only weakly.
      
      While this will not guarantee proper promise stack management, it will
      at least ensure that edge cases don't lead to catastrophic (debugger
      only) leaks.
      
      Bug: chromium:1292063
      Change-Id: I9c293ca2032de3a59e1e9624f132d37187805567
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545176
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79594}
      3eb6b7ac
  2. 10 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [inspector] Capture stack trace only once for JSError objects. · 765ca6a0
      Benedikt Meurer authored
      When creating a new JSError object (or using the non-standard API
      `Error.captureStackTrace`) V8 would previously capture the "simple stack
      trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
      standard `error.stack` property, and if the inspector was active also
      capture the "detailed stack trace" (as FixedArray of StackFrameInfo
      instances). This turns out to be quite a lot of overhead, both in terms
      of execution time as well as memory pressure, especially since the
      information needed for the inspector is a proper subset of the
      information needed by `error.stack`.
      
      So this CL addresses the above issue by capturing only the "simple stack
      trace" (in the common case) and computing the "detailed stack trace"
      from the "simple stack trace" when on demand. This is accomplished by
      introducing a new ErrorStackData container that is used to store the
      stack trace information on JSErrors when the inspector is active. When
      capturing stack trace for a JSError object while the inspector is
      active, we take the maximum of the program controlled stack trace limit
      and the inspector requested stack trace limit, and memorize the program
      controlled stack trace limit for later formatting (to ensure that the
      presence of the inspector is not observable by the program).
      
      On the `standalone.js` benchmark from crbug.com/1283162 (with the
      default max call stack size of 200) we reduce execution time by around
      16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
      regression in crbug.com/1280831), we are 6% faster now.
      
      Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
      Bug: chromium:1280831, chromium:1278650, chromium:1258599
      Bug: chromium:1280803, chromium:1280832, chromium:1280818
      Fixed: chromium:1283162
      Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78542}
      765ca6a0
  3. 03 Jan, 2022 1 commit
    • 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
  4. 15 Dec, 2021 1 commit
  5. 06 Dec, 2021 1 commit
  6. 17 May, 2021 1 commit
    • Philip Pfaffe's avatar
      Reland "[ic] Fix handling of API properties with side effects" · b4942eb3
      Philip Pfaffe authored
      This is a reland of 0ce36e7d
      
      The reland includes two fixes:
      - Move the EvaluateGlobalForTesting into libv8 to avoid linkage issues
        and to avoid having to export ThreadLocalTop symbols.
      - Give the ExecutionMode enum a uint8_t backing type to avoid endianess
        issues.
      
      Original change's description:
      > [ic] Fix handling of API properties with side effects
      >
      > DebugEvaluate can evaluate expressions in side-effect-free mode, where
      > any operation that would cause observable side effects throws an
      > exception. Currently, when accessors are backed by callbacks, it's
      > possible that ICs call those accessors directly, bypassing the
      > side-effect checks. This CL introduces a bailouts to runtime in those
      > cases.
      >
      > Fixed: chromium:1201781
      > Also-By: ishell@chromium.org, pfaffe@chromium.org
      > Change-Id: Ie53bfb2bff7b3420f2b27091e8df6723382cf53c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857634
      > Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74507}
      
      Fixes: v8:11761
      Change-Id: I58cde8bd11ba0fc9d83adc19fa87733628ab6c13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891829Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74602}
      b4942eb3
  7. 10 May, 2021 1 commit
    • Nico Hartmann's avatar
      [Torque] Finalize torque-generated synchronized accessors · 8da583ee
      Nico Hartmann authored
      Torque-generated relaxed/acquire/release accessors now expect an
      additional Tag argument to be more consistent with handwritten
      accessors.
      
      Torque's annotations are renamed from @relaxedRead, @relaxedWrite,
      @acquireRead and @releaseWrite to @cppRelaxedLoad, @cppRelaxedStore,
      @cppAcquireLoad and @cppReleaseStore, repesectively. This renaming
      shall better reflect the fact that those annotations just generate
      corresponding synchronization on the generated C++ accessors
      (not CSA code) and be more consistent with the C++ side of things
      where "Load" and "Store" is used instead of "Read" and "Write".
      
      This CL uses these new annotations on a few fields in DebugInfo and
      FunctionTemplateInfo to have Torque generate accessors automatically.
      
      Bug: v8:11122
      Change-Id: Ibdf3e6b37a254605ff69ba9a50d7b1646790ea15
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876857Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74463}
      8da583ee
  8. 11 Feb, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Generate accessors for struct-typed class fields · 6160a767
      Seth Brenith authored
      Torque generates runtime accessor member functions for most class fields
      that are defined in .tq files, but fields with struct types are
      currently omitted. This change adds those accessors. As an example, if a
      .tq file defines the following:
      
        struct InternalClassStructElement {
          a: Smi;
          b: Smi;
        }
      
        class InternalClassWithStructElements extends HeapObject {
          const count: Smi;
          entries[count]: InternalClassStructElement;
        }
      
      Then the following accessors are generated to get and set each struct
      field within the 'entries' field:
      
        inline int entries_a(int i) const;
        inline void set_entries_a(int i, int value);
      
        inline int entries_b(int i) const;
        inline void set_entries_b(int i, int value);
      
      Bug: v8:7793
      Change-Id: Ia40b5918e9d09f53ad8e78bc33f8629b8d6a79fe
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676926Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72662}
      6160a767
  9. 08 Jan, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Remove special wasm RemoteObject type. · cde7a77e
      Benedikt Meurer authored
      Previously we had introduced a special `v8::internal::WasmValue` type
      which we used to expose Wasm values to the Scope view in Chromium
      DevTools. The problem however is that these values cannot be exposed to
      JavaScript (and in particular not to Debug Evaluate), which means that
      particularly for v128 and i64 we have inconsistent representations
      across the various parts of DevTools.
      
      This change removes the `wasm` type from the RemoteObject and all the
      adjacent logic, and paves the way for a uniform representation of Wasm
      values throughout DevTools. For i64 we will simply use BigInt
      consistently everywhere, and for i32, f32 and f64 we'll just use Number.
      For externref we will represent the values as-is directly. For v128
      values we currently use a Uint8Array, but will introduce a dedicated
      WasmSimd128 class in a follow-up CL.
      
      Bug: chromium:1071432
      Fixed: chromium:1159402
      Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71962}
      cde7a77e
  10. 30 Nov, 2020 1 commit
  11. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  12. 25 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] refactor: use -tq only in filenames derived from .tq files" · 21b58516
      Tobias Tebbi authored
      This is a reland of 64caf2b0
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      >
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      >
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      >
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      Bug: v8:7793
      TBR: hpayer@chromium.org jgruber@chromium.org
      Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70137}
      21b58516
  13. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  14. 27 May, 2020 1 commit
  15. 26 May, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque][cleanup] Use more precise field types in a few classes" · 16cb2d94
      Seth Brenith authored
      This reverts commit 4e5fabae.
      
      Reason for revert: performance regressions chromium:1085305, chromium:1084978
      
      Original change's description:
      > [torque][cleanup] Use more precise field types in a few classes
      > 
      > This change updates some Torque-defined classes to include more precise
      > field types where possible. It also updates those classes to use
      > @generateCppClass. One field was removed because it's unused
      > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo
      > actually became less precise because they're based on Script::name,
      > which is an embedder-provided untyped Local<Value>. (Automatically
      > generated accessors pointed out this bug easily.)
      > 
      > This change also includes a couple of minor fixes in Torque.
      > 
      > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67907}
      
      TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67972}
      16cb2d94
  16. 19 May, 2020 1 commit
  17. 11 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque][cleanup] Simplify some Torque-defined classes · e7693985
      Seth Brenith authored
      This CL is pretty mechanical; I just iterated through some Torque
      classes making the following changes:
      
      - Use @generateCppClass if it seems easy to
      - Use @generatePrint if the existing printer doesn't do anything special
      - Fix up any imprecise field types
      
      It also includes two minor changes to implementation-visitor:
      
      - Add a new -inl.h file with the things needed for
        torque-generated/class-definitions-tq.cc so we don't need to keep
        changing the compiler when we add @generateCppClass.
      - Avoid emitting incorrect accessors for ExternalPointers. This isn't
        strictly necessary for correctness, as the accessors defined in C++
        already hide the ones inherited from generated code, but it makes me
        feel safer.
      
      Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#67719}
      e7693985
  18. 15 Apr, 2020 1 commit
  19. 06 Apr, 2020 1 commit
  20. 18 Mar, 2020 1 commit
  21. 26 Feb, 2020 2 commits
    • Seth Brenith's avatar
      Move a bunch of bitfield definitions to Torque · 74131bdd
      Seth Brenith authored
      This allows Torque code to refer to these bitfields (not currently
      relevant for any of these classes), and allows the postmortem debugging
      API to provide details about these bitfields.
      
      Change-Id: I79c74a3c5ef1f77e839720a4e8ee1f8482a576ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049870
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66471}
      74131bdd
    • Seth Brenith's avatar
      Reland "[torque] Support bitfield structs stored within Smis" · 527f9de1
      Seth Brenith authored
      This reverts commit 4dc1fb4e.
      
      Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.
      
      Original change's description:
      > Revert "[torque] Support bitfield structs stored within Smis"
      >
      > This reverts commit e5e4ea96.
      >
      > Reason for revert: mysterious performance regression chromium:1052756
      >
      > Original change's description:
      > > [torque] Support bitfield structs stored within Smis
      > >
      > > This change moves the definition of the bits stored in DebugInfo::flags
      > > to Torque, and updates the only Torque usage of that field to use more
      > > natural syntax. This is intended as an example of common patterns found
      > > in various other classes. Several supporting changes are required:
      > >
      > > 1. Add a new type representing a bitfield struct stored within a Smi. It
      > >    is currently called SmiTagged, but I'm open to suggestions.
      > > 2. Add an enum-style output for Torque bitfield structs whose bitfields
      > >    occupy only one bit each.
      > > 3. Add a new case to MachineOperatorReducer that makes the generated
      > >    code for IncBlockCounter match with what was generated before this
      > >    change.
      > > 4. Add support for reporting these bitfields in the postmortem debugging
      > >    API. The format matches existing bitfields but with an offset value
      > >    that includes the SMI shift size.
      > >
      > > Bug: v8:7793
      > > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      > > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66182}
      >
      > Bug: chromium:1052756, v8:7793
      > Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66349}
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1052756, v8:7793
      Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66465}
      527f9de1
  22. 19 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque] Support bitfield structs stored within Smis" · 4dc1fb4e
      Seth Brenith authored
      This reverts commit e5e4ea96.
      
      Reason for revert: mysterious performance regression chromium:1052756
      
      Original change's description:
      > [torque] Support bitfield structs stored within Smis
      >
      > This change moves the definition of the bits stored in DebugInfo::flags
      > to Torque, and updates the only Torque usage of that field to use more
      > natural syntax. This is intended as an example of common patterns found
      > in various other classes. Several supporting changes are required:
      >
      > 1. Add a new type representing a bitfield struct stored within a Smi. It
      >    is currently called SmiTagged, but I'm open to suggestions.
      > 2. Add an enum-style output for Torque bitfield structs whose bitfields
      >    occupy only one bit each.
      > 3. Add a new case to MachineOperatorReducer that makes the generated
      >    code for IncBlockCounter match with what was generated before this
      >    change.
      > 4. Add support for reporting these bitfields in the postmortem debugging
      >    API. The format matches existing bitfields but with an offset value
      >    that includes the SMI shift size.
      >
      > Bug: v8:7793
      > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66182}
      
      Bug: chromium:1052756, v8:7793
      Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66349}
      4dc1fb4e
  23. 18 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Assign CoverageInfo an instance type · 6ce65b96
      Seth Brenith authored
      This allows CoverageInfo to be distinguished from other kinds of
      FixedArray at runtime. I also updated it to use untagged data since it
      only stores ints, since that seems like the generally right thing to do
      (even though I doubt anybody allocates enough of these to notice the
      reduced GC work).
      
      Related Torque changes:
      - Allow structs containing untagged data to be used as class fields.
        This requires classifying them into the tagged or untagged sections of
        the class layout, and checking that their alignment requirements are
        met when stored in a packed array.
      - Generate a struct containing struct field offsets, so we can ensure
        that the layouts defined in Torque and C++ code match. Of course it
        would be nice to generate a lot more (indexed accessors, synchronized
        accessors, GC visitors, etc.), but we can't do it all at once.
      
      Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66318}
      6ce65b96
  24. 12 Feb, 2020 1 commit
  25. 07 Feb, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Support bitfield structs stored within Smis · e5e4ea96
      Seth Brenith authored
      This change moves the definition of the bits stored in DebugInfo::flags
      to Torque, and updates the only Torque usage of that field to use more
      natural syntax. This is intended as an example of common patterns found
      in various other classes. Several supporting changes are required:
      
      1. Add a new type representing a bitfield struct stored within a Smi. It
         is currently called SmiTagged, but I'm open to suggestions.
      2. Add an enum-style output for Torque bitfield structs whose bitfields
         occupy only one bit each.
      3. Add a new case to MachineOperatorReducer that makes the generated
         code for IncBlockCounter match with what was generated before this
         change.
      4. Add support for reporting these bitfields in the postmortem debugging
         API. The format matches existing bitfields but with an offset value
         that includes the SMI shift size.
      
      Bug: v8:7793
      Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66182}
      e5e4ea96
  26. 09 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [cleanup] Don't inherit from Tuple2 and Tuple3 · 24c23947
      Seth Brenith authored
      This change updates CachedTemplateObjectMap, BreakPointInfo, and
      BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3.
      It also removes Tuple3 because nothing else used Tuple3. By avoiding
      tuple types, we get various benefits that Torque can provide:
      - stricter debug verifier functions
      - accessors, cast functions, and printers are generated
      - BreakPoint and BreakPointInfo have different instance types, so you
        can tell them apart at runtime or in a debugger
      
      Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65668}
      24c23947
  27. 18 Dec, 2019 1 commit
  28. 15 Nov, 2019 1 commit
  29. 07 Oct, 2019 1 commit
  30. 13 Sep, 2019 1 commit
  31. 23 May, 2019 1 commit
  32. 24 Apr, 2019 1 commit
    • Jakob Gruber's avatar
      [coverage] Reduce IncBlockCounter overhead · ae6a47ba
      Jakob Gruber authored
      When collecting JS block coverage, we track block execution counts on
      so-called CoverageInfo objects. Generated bytecode and native code
      contains inlined snippets of code to increment the appropriate
      counters.
      
      These used to be implemented as calls to the IncBlockCounter runtime
      function. Each call incurred the entire CEntry overhead.
      
      This CL reduces that overhead by moving logic over into a new
      IncBlockCounter TFS builtin. The builtin is called directly from
      bytecode, and lowered to the same builtin call for optimized code.
      
      Drive-by: Tweak CoverageInfo layout to generate faster code.
      
      Tbr: jarin@chromium.org
      Bug: v8:9149, v8:6000
      Change-Id: I2d7cb0db649edf7c56b5ef5a4683d27b1c34605c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571420Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60981}
      ae6a47ba
  33. 29 Mar, 2019 1 commit
  34. 13 Feb, 2019 1 commit
  35. 09 Jan, 2019 1 commit
  36. 26 Dec, 2018 1 commit
  37. 18 Dec, 2018 1 commit
  38. 17 Dec, 2018 1 commit