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. 12 Mar, 2021 1 commit
    • Z Nguyen-Huu's avatar
      Reland "[v8windbg] Add more items in the Locals pane" · d193e90c
      Z Nguyen-Huu authored
      This is a reland of 19b62d0b
      
      Fixing the misalignment issue founded in usban build by doing four-byte
      comparison: compressing the "expected" values such as script.name() and
      passing them to CheckProp as type Tagged_t
      
      Original change's description:
      > [v8windbg] Add more items in the Locals pane
      >
      > Add more items in the Locals pane representing the JS function name,
      > source file name, and character offset within the source file, so
      > that the user doesn’t need to dig through the shared_function_info to
      > find them.
      >
      > Change-Id: I5d42b3c9542885a72e81613503d1d5abf51870b5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712310
      > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      > Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#73282}
      
      Change-Id: Idd77f61905651fbcfae5f5b590094639bc205834
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2744959Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#73359}
      d193e90c
  3. 11 Mar, 2021 3 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored
      This is a reland of 80f5dfda. A condition
      in pipeline.cc was inverted, which lead to a CSA verifier error.
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      TBR=jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored
      This reverts commit 80f5dfda.
      
      Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      Bug: v8:11238
      Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored
      This is the biggest chunk, including
      - all of src/wasm,
      - torque file for wasm objects,
      - torque file for wasm builtins,
      - wasm builtins,
      - wasm runtime functions,
      - int64 lowering,
      - simd scala lowering,
      - WasmGraphBuilder (TF graph construction for wasm),
      - wasm frame types,
      - wasm interrupts,
      - the JSWasmCall opcode,
      - wasm backing store allocation.
      
      Those components are all recursively entangled, so I found no way to
      split this change up further.
      
      Some includes that were recursively included by wasm headers needed to
      be added explicitly now.
      
      backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      because it only tests wasm backing stores. This file is excluded from
      no-wasm builds then.
      
      R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      
      Bug: v8:11238
      Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
  4. 08 Mar, 2021 2 commits
  5. 19 Jan, 2021 1 commit
  6. 11 Nov, 2020 1 commit
  7. 21 Sep, 2020 1 commit
  8. 18 Jun, 2020 1 commit
    • Dan Elphick's avatar
      Reland "[heap] Make ReadOnlySpace use bump pointer allocation" · 32b911f9
      Dan Elphick authored
      This reverts commit f78d69fa.
      
      With https://chromium-review.googlesource.com/c/v8/v8/+/2243216,
      incorrect MemoryChunk::FromHeapObject uses are now fixed.
      
      Original change's description:
      > Revert "[heap] Make ReadOnlySpace use bump pointer allocation"
      > 
      > This reverts commit 81c34968 and also
      > 490f3580 which depends on the former.
      > 
      > Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438
      > Original change's description:
      > > [heap] Make ReadOnlySpace use bump pointer allocation
      > >
      > > This changes ReadOnlySpace to no longer be a PagedSpace but instead it
      > > is now a BaseSpace. BasicSpace is a new base class that Space inherits
      > > from and which has no allocation methods and does not dictate how the
      > > pages should be held.
      > >
      > > ReadOnlySpace unlike Space holds its pages as a
      > > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
      > > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
      > > cannot be held in a heap::List. This is desirable since with pointer
      > > compression we would like to remap these pages to different memory
      > > addresses which would be impossible with a heap::List.
      > >
      > > Since ReadOnlySpace no longer uses most of the code from the other
      > > Spaces it makes sense to simplify its memory allocation to use a simple
      > > bump pointer and always allocate a new page whenever an allocation
      > > exceeds the remaining space on the final page.
      > >
      > > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
      > > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#68137}
      > 
      > TBR=ulan@chromium.org,delphick@chromium.org
      > 
      > # Not skipping CQ checks because original CL landed > 1 day ago.
      > 
      > Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68211}
      
      TBR=ulan@chromium.org,delphick@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: Id5b3cce41b5dec1dca816c05848d183790b1cc05
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250254Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68407}
      32b911f9
  9. 05 Jun, 2020 1 commit
    • Dan Elphick's avatar
      Revert "[heap] Make ReadOnlySpace use bump pointer allocation" · f78d69fa
      Dan Elphick authored
      This reverts commit 81c34968 and also
      490f3580 which depends on the former.
      
      Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438
      Original change's description:
      > [heap] Make ReadOnlySpace use bump pointer allocation
      >
      > This changes ReadOnlySpace to no longer be a PagedSpace but instead it
      > is now a BaseSpace. BasicSpace is a new base class that Space inherits
      > from and which has no allocation methods and does not dictate how the
      > pages should be held.
      >
      > ReadOnlySpace unlike Space holds its pages as a
      > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
      > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
      > cannot be held in a heap::List. This is desirable since with pointer
      > compression we would like to remap these pages to different memory
      > addresses which would be impossible with a heap::List.
      >
      > Since ReadOnlySpace no longer uses most of the code from the other
      > Spaces it makes sense to simplify its memory allocation to use a simple
      > bump pointer and always allocate a new page whenever an allocation
      > exceeds the remaining space on the final page.
      >
      > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68137}
      
      TBR=ulan@chromium.org,delphick@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68211}
      f78d69fa
  10. 03 Jun, 2020 1 commit
    • Dan Elphick's avatar
      [heap] Make ReadOnlySpace use bump pointer allocation · 81c34968
      Dan Elphick authored
      This changes ReadOnlySpace to no longer be a PagedSpace but instead it
      is now a BaseSpace. BasicSpace is a new base class that Space inherits
      from and which has no allocation methods and does not dictate how the
      pages should be held.
      
      ReadOnlySpace unlike Space holds its pages as a
      std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses
      BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and
      cannot be held in a heap::List. This is desirable since with pointer
      compression we would like to remap these pages to different memory
      addresses which would be impossible with a heap::List.
      
      Since ReadOnlySpace no longer uses most of the code from the other
      Spaces it makes sense to simplify its memory allocation to use a simple
      bump pointer and always allocate a new page whenever an allocation
      exceeds the remaining space on the final page.
      
      Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68137}
      81c34968
  11. 04 May, 2020 1 commit
  12. 09 Mar, 2020 1 commit
    • 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
  13. 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
  14. 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
  15. 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
  16. 23 Jan, 2020 1 commit
  17. 07 Jan, 2020 1 commit
  18. 12 Dec, 2019 1 commit
    • Seth Brenith's avatar
      Fix brittleness of GetObjectProperties test · 51d2e988
      Seth Brenith authored
      Part of the GetObjectProperties test case is for verifying the human-
      readable brief object description string that GetObjectProperties
      returns. That string might look something like this:
      
      "xy" (0x28f038d5 <v8::internal::SeqOneByteString>)
      
      GetObjectProperties also tries to detect known immortal objects by
      recognizing their addresses, which is useful in crash dumps with limited
      memory. The recognized object name, if it exists, is prepended to the
      description string. In order to provide this data accurately (in builds
      without pointer compression), GetObjectProperties relies on the caller
      to provide the addresses of the first pages in read-only space, map
      space, and old space. If the caller doesn't provide those addresses,
      then GetObjectProperties does the best it can with limited information
      and reports possible matches based on an object's offset within the heap
      page that contains it. So the result string might look like this, if the
      object happened to get allocated at a lucky offset within its page:
      
      maybe LoadHandler3Map "xy" (0x28f038d5 <v8::internal::SeqOneByteString>)
      
      As a result, when testing these descriptions, we should generally check
      that they contain the interesting data rather than that they start with
      it, because some incorrect "maybe" match with a known object might be
      included at the beginning.
      
      Bug: v8:10034
      Change-Id: I0cf5afd67793a239614aba3665ef57cd2d663a47
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1950233Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65432}
      51d2e988
  19. 26 Nov, 2019 1 commit
    • Seth Brenith's avatar
      [tools] Add in-object properties to debug_helper · dcb828b4
      Seth Brenith authored
      Until now, the in-object properties on JSObject have been invisible to
      tools using the postmortem debugging library. With this change, those
      tools will get enough information to show a flat list of property
      values. This is still less powerful than the runtime printers, which can
      show the corresponding key for each value, but it's a big step up from
      manually inspecting memory.
      
      This change basically requires a reimplementation of
      Map::GetInObjectProperties for postmortem debugging. I'm not
      enthusiastic about duplicating this logic, but it's pretty small and I
      don't see any good alternatives.
      
      As a drive-by cleanup, I moved some inline string literals into a batch
      of constexpr char arrays.
      
      Bug: v8:9376
      Change-Id: Ia24c05f6e823086babaa07882d0d320ab9a225db
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930174Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65183}
      dcb828b4
  20. 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
  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. 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
  23. 09 Sep, 2019 1 commit
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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