1. 12 Apr, 2021 1 commit
    • Wenyu Zhao's avatar
      Allowing map word to be used for other state in GC header. · 5e0b94c4
      Wenyu Zhao authored
      This CL adds features to pack/unpack map words.
      
      Currently V8 cannot store extra metadata in object headers -- because V8
      objects do not have a proper header, but only a map pointer at the start
      of the object. To store per-object metadata like marking data, a side
      table is required as the per-object metadata storage.
      
      This CL enables V8 to use higher unused bits in a 64-bit map word as
      per-object metadata storage. Map pointer stores come with an extra step
      to encode the metadata into the pointer (we call it "map packing").
      Map pointer loads will also remove the metadata bits as well (we call it
      "map packing").
      
      Since the map word is no longer a valid pointer after packing, we also
      change the tag of the packed map word to make it looks like a Smi. This
      helps various GC and barrier code to correctly skip them instead of
      blindly dereferencing this invalid pointer.
      
      A ninja flag `v8_enable_map_packing` is provided to turn this
      map-packing feature on and off. It is disabled by default.
      
      * Only works on x64 platform, with `v8_enable_pointer_compression`
        set to `false`
      
      Bug: v8:11624
      Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73915}
      5e0b94c4
  2. 09 Mar, 2021 1 commit
  3. 19 Jan, 2021 1 commit
  4. 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
  5. 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
  6. 22 Apr, 2020 1 commit
    • Seth Brenith's avatar
      Reland "[torque] Allow storing to bitfield structs that are stored in Smis" · a9270e2b
      Seth Brenith authored
      This is a reland of 80843eda
      
      Original change's description:
      > [torque] Allow storing to bitfield structs that are stored in Smis
      > 
      > This change:
      > 1. Updates the Torque compiler to allow direct access to bitfields that
      >    are packed within Smi values, which previously would have required a
      >    separate untagging step,
      > 2. Updates JSRegExpStringIterator to represent its flags in Torque,
      > 3. Adds reduction cases in MachineOperatorReducer for when the input to
      >    a branch or the left-hand side of a Word32Equals is based on a 64-bit
      >    shift-and-mask operation which has been truncated to 32 bits, as is
      >    the case in the code generated by step 1, and
      > 4. Adds a reduction case in MachineOperatorReducer to remove an extra
      >    Word64And operation added by step 1.
      > 
      > Bug: v8:7793
      > Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67290}
      
      Bug: v8:7793
      Change-Id: I783b6ec080042fec0e922927f6675dede458a072
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159731Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67305}
      a9270e2b
  7. 21 Apr, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] Allow storing to bitfield structs that are stored in Smis" · db61168a
      Francis McCabe authored
      This reverts commit 80843eda.
      
      Reason for revert: Causes compilation failure on macs
      
      https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934?
      
      
      Original change's description:
      > [torque] Allow storing to bitfield structs that are stored in Smis
      > 
      > This change:
      > 1. Updates the Torque compiler to allow direct access to bitfields that
      >    are packed within Smi values, which previously would have required a
      >    separate untagging step,
      > 2. Updates JSRegExpStringIterator to represent its flags in Torque,
      > 3. Adds reduction cases in MachineOperatorReducer for when the input to
      >    a branch or the left-hand side of a Word32Equals is based on a 64-bit
      >    shift-and-mask operation which has been truncated to 32 bits, as is
      >    the case in the code generated by step 1, and
      > 4. Adds a reduction case in MachineOperatorReducer to remove an extra
      >    Word64And operation added by step 1.
      > 
      > Bug: v8:7793
      > Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67290}
      
      TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org
      
      Change-Id: Ifa683c92631291c9437438682b6efb2e12862682
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67291}
      db61168a
    • Seth Brenith's avatar
      [torque] Allow storing to bitfield structs that are stored in Smis · 80843eda
      Seth Brenith authored
      This change:
      1. Updates the Torque compiler to allow direct access to bitfields that
         are packed within Smi values, which previously would have required a
         separate untagging step,
      2. Updates JSRegExpStringIterator to represent its flags in Torque,
      3. Adds reduction cases in MachineOperatorReducer for when the input to
         a branch or the left-hand side of a Word32Equals is based on a 64-bit
         shift-and-mask operation which has been truncated to 32 bits, as is
         the case in the code generated by step 1, and
      4. Adds a reduction case in MachineOperatorReducer to remove an extra
         Word64And operation added by step 1.
      
      Bug: v8:7793
      Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67290}
      80843eda
  8. 18 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] add const references and disallow const class field writes · d7e02ea4
      Tobias Tebbi authored
      - Allow type expression for abstract type supertypes.
        For consistency, and ease of implementation, also allow this for enums.
      - Allow subtyping of structs. This requires changing all places where we
        checked for struct types and instead check if we have a subtype of a
        struct type.
      - This allows defining two subtypes of the Reference<T> struct for
        mutable and constant references. Mutable references are a subtype of
        constant references.
      - &T desugars to MutableReference<T>
        const &T desugars to ConstReference<T>
      - A const field of a class produces a constant reference.
        A const field of a mutable reference to a struct is const.
        A mutable field of a const reference to a struct is const.
      - It is possible to assign a new struct value to a mutable reference to
        a struct, even if the struct contains const fields. This is analogous
        to allowing assignments of let-bound structs with constant fields.
      
      Not in this CL:
      - A notion of const slices.
      - Applying const to appropriate class fields.
      
      Bug: v8:7793
      Change-Id: I6e7b09d44f54db25f8bf812be5f3b554b80414e0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096615Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66759}
      d7e02ea4
  9. 09 Mar, 2020 2 commits
    • Seth Brenith's avatar
      [tools] Fix v8windbg behavior on Map's bit_field2 · 8b1a5681
      Seth Brenith authored
      Bill kindly pointed out to me that v8windbg was not handling bit_field2
      correctly. The issue was that the constexpr type for ElementsKind was,
      somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully-
      qualified type name like "v8::internal::ElementsKind". This change
      addresses the problem in two ways:
      1. Update v8windbg's type resolution logic to resolve type names as if
         they were used in the v8::internal namespace. This makes it more
         consistent with how those type names are used in other generated
         Torque code, reducing surprises and the number of times we have to
         write `v8::internal::` in .tq files.
      2. Add compile-time verification that any constexpr type name used as a
         string in class-debug-readers-tq.cc can also resolve as a type name.
      
      Bug: v8:9376
      Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66633}
      8b1a5681
    • Tobias Tebbi's avatar
      [torque] Generate GC object visitors for Torque classes · 4f4d73f2
      Tobias Tebbi authored
      In the process:
      
      * Augment C++-generated Torque classes with SizeFor methods to
        calculate size of instances.
      
      * Add a new "@generateBodyDescriptor" annotation that causes Torque to
        generate C++ BodyDescriptors code that can be used to visit objects
        compatible with existing V8 mechanisms, e.g. GC
      
      * Fully automate C++ macro machinery so that adding non-extern Torque
        class doesn't require any C++ changes, including ensuring generation
        of instance types and proper boilerplate for validators and
        printers.
      
      * Make handling of @export a true annotation, allowing the modifier to
        be used on class declarations.
      
      * Add functionality such that classes with the @export annotation are
        available to be used from C++. Field accessors for exported classes
        are public and factory methods are generated to create instances of
        the objects from C++.
      
      * Change the Torque compiler such that Non-exported classes implicitly
        have the @generateBodyDescriptor annotation added and causes both
        verifiers and printers to be generated.
      
      * Switch non-extern Torque classes from using existing Struct-based
        machinery to being first-class classes that support more existing
        Torque class features.
      
      Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66621}
      4f4d73f2
  10. 26 Feb, 2020 1 commit
    • 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
  11. 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
  12. 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
  13. 23 Jan, 2020 1 commit
  14. 16 Jan, 2020 1 commit
  15. 07 Jan, 2020 1 commit
  16. 20 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] multiple arrays in one object · 59e8d45a
      Tobias Tebbi authored
      This allows the definition of classes with several arrays and ports
      SmallOrderedHashTable subclasses to Torque as an example, including
      the existing CSA allocation functions for them.
      
      Overview of changes:
      - Introduce ResidueClass to encapsulate the modulo-arithmetic
        necessary to do alignment checks.
      - Add MachineOperatorReducer to the CSA pipeline to address now
        missing CSA ad-hoc constant folding that got blocked by a
        temporary phi.
      - Allow assignments to references to structs. This is needed to
        initialize the data_table part of SmallOrderedHashMap.
      - Make the NumberLiteralExpression AST-node store a double instead
        of a string. This is necessary to detect arrays with constant size
        used for padding.
      - Turn offsets into base::Optional<size_t> to ensure we don't use
        an invalid or statically unknown offset.
      - Remove CreateFieldReferenceInstruction since it doesn't work for
        complex offset computations and the logic can be expressed better
        in ImplementationVisitor.
      - Validate alignment of structs embedded in classes.
      
      Bug: v8:10004 v8:7793
      Change-Id: Ifa414b42278e572a0c577bf9da3d37f80771a258
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958011
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65538}
      59e8d45a
  17. 12 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      [torque] allow expressions for array lengths · 6b663123
      Tobias Tebbi authored
      This allows arbitrary expressions to specify the length of an array.
      These expressions get access to globally declared things and the
      preceding fields of the current object.
      Unfortunately, this breaks generated C++ runtime code, so as a
      workaround, I special-case expressions that are just an identifier
      and handle them as before. We might want to support more cases there
      in the future, probably also with special-casing since having a full
      C++ back-end for Torque is infeasible.
      
      Bug: v8:10004 v8:7793
      
      Change-Id: I0d5d1200c0e727766beed7bfb2d43a8abb9cacf0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1942610
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65427}
      6b663123
  18. 06 Dec, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Add bitfield declarations · 57074692
      Seth Brenith authored
      This change is the first part of adding Torque support for a "bitfield
      struct", which represents a set of bitfields packed together into an
      integer value. With this change, Torque can generate the list of
      BitField template specializations that allow runtime code to use the
      bitfield values. The flags used in SharedFunctionInfo are converted to
      Torque to exercise this functionality. Bitfield values are not yet
      accessible directly from Torque code.
      
      Bug: v8:7793
      Change-Id: I9e4a3df7c847111b6e02e513f175dbf938b0be35
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1949047
      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@{#65371}
      57074692
  19. 20 Nov, 2019 1 commit
    • Seth Brenith's avatar
      [torque][tools] Define layout of DescriptorArray for postmortem tools · 6b11b700
      Seth Brenith authored
      This change defines a way that v8_debug_helper can describe object
      fields which are packed structs, and uses it for the "descriptors" field
      in DescriptorArray.
      
      In more detail:
      - debug-helper.h (the public interface for v8_debug_helper) adds a size
        and an optional list of struct properties to ObjectProperty.
      - debug-helper-internal.h mirrors those changes to the internal class
        hierarchy which maintains proper unique_ptr ownership.
      - In src/torque/class-debug-reader-generator.cc,
        - Some existing logic is moved into smaller functions.
        - New logic is added to generate the field list for structs. Example
          output is included in a comment above the function
          GenerateGetPropsChunkForField.
      
      Bug: v8:9376
      Change-Id: I531acac039ccb42050641448a4cbaec26186a7bc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1894362
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65079}
      6b11b700
  20. 18 Nov, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Verify nested struct fields in classes · 88a2d011
      Seth Brenith authored
      As one of several steps involved in supporting struct-valued fields
      within classes, this CL generates type verification code for the data
      contained in those structs.
      
      In order to generate verification code, Torque needs to know about
      struct field offsets and the total size of structs. Those calculations
      are added to StructType itself and the function TypeVisitor::ComputeType
      which initializes the StructType. I repurposed the Field::offset value
      to behave in structs more like it does in classes (it had previously
      indicated the index of a field within a struct, but nobody used that
      value). Overall this works okay, and I think it's less confusing to have
      Field::offset mean the same thing everywhere. However, some struct
      fields have types with unknown size (Field::GetFieldSizeInformation
      fails), so those fields are now marked with offset Field::kInvalidOffset
      to indicate that the structs containing them should not be used within
      class fields or anywhere else that requires packed layout.
      
      Bug: v8:7793
      Change-Id: If2677c8c81efc85e63b4bfb831d818a748427e18
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897247
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65016}
      88a2d011
  21. 16 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [tools] Add list of classes to v8_debug_helper · 4d0360aa
      Seth Brenith authored
      This change extends v8_debug_helper to export a new method that returns
      a list of all known heap object types.
      
      Why? We can substantially improve the user experience in our work-in-
      progress WinDbg extension if we register handlers not only for
      v8::internal::Object but for every specific HeapObject type. This has
      two benefits:
      
      - You save a click: if you're expanding a local variable of a more
        specific type than Object, you can see properties immediately rather
        than first needing to expand a sub-item that casts the variable to
        Object.
      - You retain the type hint: GetObjectProperties accepts a type hint
        string, and it's super important to pass it when working in a crash
        dump because the object's Map is probably inaccessible. If we have to
        cast to Object first, we lose this data.
      
      Bug: v8:9376
      Change-Id: I4d635a1826574a3d08ac657e848e1fe7b83849fe
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822859Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#64331}
      4d0360aa
  22. 14 Oct, 2019 1 commit
  23. 11 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Generate instance types · 8c7ae314
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit
      
      Changes from the design doc:
      - Changed to use 'class' declarations rather than 'type' declarations
        for things that need instance types but whose layout is not known to
        Torque. These declarations end with a semicolon rather than having a
        full set of methods and fields surrounded by {}. If the class's name
        should not be treated as a class name in generated output (because
        it's actually a template, or doesn't exist at all), we use the
        standard 'generates' clause to declare the most appropriate C++ class.
      - Removed @instanceTypeName.
      - @highestInstanceType became @highestInstanceTypeWithinParentClassRange
        to indicate a semantic change: it no longer denotes the highest
        instance type globally, but only within the range of values for its
        immediate parent class. This lets us use it for Oddball, which is
        expected to be the highest primitive type.
      - Added new abstract classes JSCustomElementsObject and JSSpecialObject
        to help with some range checks.
      - Added @lowestInstanceTypeWithinParentClassRange so we can move the new
        classes JSCustomElementsObject and JSSpecialObject to the beginning of
        the JSObject range. This seems like the least-brittle way to establish
        ranges that also include JSProxy (and these ranges are verified with
        static assertions in instance-type.h).
      - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue.
      - Renamed @instanceTypeFlags to @reserveBitsInInstanceType.
      
      This change introduces the new annotations and adds the ability for
      Torque to assign instance types that satisfy those annotations. Torque
      now emits two new macros:
      - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the
        InstanceType enumeration
      - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String
        parts of INSTANCE_TYPE_LIST
      
      The design document mentions a couple of other macro lists that could
      easily be replaced, but I'd like to defer those to a subsequent checkin
      because this one is already pretty large.
      
      Bug: v8:7793
      Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64258}
      8c7ae314
  24. 20 Sep, 2019 1 commit
    • Seth Brenith's avatar
      [tools] Use instance types of known Maps in v8_debug_helper · 1d3c4975
      Seth Brenith authored
      If we can read an object's Map pointer but not any data from the Map
      itself, we may still be able to accurately describe the object's type if
      the Map pointer matches one of the known Maps from the snapshot.
      GetObjectProperties uses that data in one of two ways:
      - If it is sure that the Map pointer matches a known Map, then it uses
        the type from that Map and continues as if it read the type normally.
      - If the Map pointer is at the right offset within a heap page to match
        a known Map, but the caller didn't provide the addresses of the first
        pages in Map space or read-only space, then the type of that Map is
        just a guess and gets returned in a separate array. This gives the
        caller the opportunity to present guessed types to the user, and
        perhaps call again using the guessed type as the type hint.
      
      Bug: v8:9376
      Change-Id: I187f67b77e76699863a14534a9d635b79f654124
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787986
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63908}
      1d3c4975
  25. 10 Sep, 2019 1 commit
  26. 30 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [tools][torque] Include string values in GetObjectProperties responses · 2ccca6c5
      Seth Brenith authored
      This change provides a quick way to see string contents in postmortem
      debugging sessions, without digging through a (possibly very large, in
      the case of ConsString) tree of properties. As well as being convenient
      for inspecting String objects, this functionality will also be necessary
      for displaying property names on JSReceiver objects. In order to support
      custom behaviors for specific classes, this change extends the existing
      generated debug reader classes with a visitor pattern.
      
      Bug: v8:9376
      Change-Id: I70eab9ea4e74ca0fab39bf5998d6a602716a4202
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771939Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63485}
      2ccca6c5
  27. 22 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [tools][torque]Improve postmortem API behavior on strings · 1a815e44
      Seth Brenith authored
      This change adds the indexed field for the characters in the definition
      of sequential string types, and introduces support for recognizing the
      various specific string types in v8_debug_helper. In an attempt to
      avoid duplicating info about string instance types, it also refactors
      String::Get so that StringShape (a simple class usable by postmortem
      tools) can dispatch using a class that defines behaviors for each
      concrete type.
      
      Bug: v8:9376
      Change-Id: Id0653040f6decddc004c73f8fe93d2187828c2c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735795
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63352}
      1a815e44
  28. 31 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Reland "Add postmortem debugging helper library" · 0921e8f2
      Seth Brenith authored
      This is a reland of 517ab73f
      
      Updates since original: now compressed pointers passed to the function
      GetObjectProperties are required to be sign-extended. Previously, the
      function allowed zero-extended values, but that led to ambiguity on
      pointers like 0x88044919: is it compressed or is the heap range actually
      centered on 0x100000000?
      
      Original change's description:
      > Add postmortem debugging helper library
      >
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      >
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      >
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      >
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      >
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      >
      > Bug: v8:9376
      >
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      Bug: v8:9376
      Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63008}
      0921e8f2
  29. 24 Jul, 2019 1 commit
    • Zhi An Ng's avatar
      Revert "Add postmortem debugging helper library" · 6747e3a1
      Zhi An Ng authored
      This reverts commit 517ab73f.
      
      Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
      
      Original change's description:
      > Add postmortem debugging helper library
      > 
      > This change begins to implement the functionality described in
      > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      > for investigating V8 state in crash dumps.
      > 
      > This change adds a new library, v8_debug_helper, for providing platform-
      > agnostic assistance with postmortem debugging. This library can be used
      > by extensions built for debuggers such as WinDbg or lldb. Its public API
      > is described by debug-helper.h; currently the only method it exposes is
      > GetObjectProperties, but we'd like to add more functionality over time.
      > The API surface is restricted to plain C-style structs and pointers, so
      > that it's easy to link from a debugger extension built with a different
      > toolchain.
      > 
      > This change also adds a new cctest file to exercise some basic
      > interaction with the new library.
      > 
      > The API function GetObjectProperties takes an object pointer (which
      > could be compressed, or weak, or a SMI), and returns a string
      > description of the object and a list of properties the object contains.
      > For now, the list of properties is entirely based on Torque object
      > definitions, but we expect to add custom properties in future updates so
      > that it can be easier to make sense of complex data structures such as
      > dictionaries.
      > 
      > GetObjectProperties does several things that are intended to generate
      > somewhat useful results even in cases where memory may be corrupt or
      > unavailable:
      > - The caller may optionally provide a type string which will be used if
      >   the memory for the object's Map is inaccessible.
      > - All object pointers are compared against the list of known objects
      >   generated by mkgrokdump. The caller may optionally provide the
      >   pointers for the first pages of various heap spaces, to avoid spurious
      >   matches. If those pointers are not provided, then any matches are
      >   prefixed with "maybe" in the resulting description string, such as
      >   "maybe UndefinedValue (0x4288000341 <Oddball>)".
      > 
      > Bug: v8:9376
      > 
      > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62882}
      
      TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9376
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62899}
      6747e3a1
  30. 23 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Add postmortem debugging helper library · 517ab73f
      Seth Brenith authored
      This change begins to implement the functionality described in
      https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit#
      for investigating V8 state in crash dumps.
      
      This change adds a new library, v8_debug_helper, for providing platform-
      agnostic assistance with postmortem debugging. This library can be used
      by extensions built for debuggers such as WinDbg or lldb. Its public API
      is described by debug-helper.h; currently the only method it exposes is
      GetObjectProperties, but we'd like to add more functionality over time.
      The API surface is restricted to plain C-style structs and pointers, so
      that it's easy to link from a debugger extension built with a different
      toolchain.
      
      This change also adds a new cctest file to exercise some basic
      interaction with the new library.
      
      The API function GetObjectProperties takes an object pointer (which
      could be compressed, or weak, or a SMI), and returns a string
      description of the object and a list of properties the object contains.
      For now, the list of properties is entirely based on Torque object
      definitions, but we expect to add custom properties in future updates so
      that it can be easier to make sense of complex data structures such as
      dictionaries.
      
      GetObjectProperties does several things that are intended to generate
      somewhat useful results even in cases where memory may be corrupt or
      unavailable:
      - The caller may optionally provide a type string which will be used if
        the memory for the object's Map is inaccessible.
      - All object pointers are compared against the list of known objects
        generated by mkgrokdump. The caller may optionally provide the
        pointers for the first pages of various heap spaces, to avoid spurious
        matches. If those pointers are not provided, then any matches are
        prefixed with "maybe" in the resulting description string, such as
        "maybe UndefinedValue (0x4288000341 <Oddball>)".
      
      Bug: v8:9376
      
      Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62882}
      517ab73f