- 12 Apr, 2021 1 commit
-
-
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: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
-
- 12 Mar, 2021 1 commit
-
-
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: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73359}
-
- 11 Mar, 2021 3 commits
-
-
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: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
-
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}
-
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: 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}
-
- 08 Mar, 2021 2 commits
-
-
Bill Budge authored
This reverts commit 19b62d0b. Reason for revert: Undefined behavior https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/15449 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: I616cd642379b97dff5fb0c66aeb6488e2f9b298b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2744420 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#73284}
-
Z Nguyen-Huu authored
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}
-
- 19 Jan, 2021 1 commit
-
-
Z Nguyen-Huu authored
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI Modify that C++ backend so that it can emit either runtime C++ or postmortem debugging code. When in postmortem debugging mode, the overall code structure would look similar with some difference: 1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor. 2. Instead of runtime class names like String, we use uintptr_t 3. When loading data from objects, instead of TaggedField<T>::load or Object::ReadField (which read from the current process), we use the MemoryAccessor and read data from the debuggee process. 4. Return values should be wrapped in the Value struct. Implement the debug accessors for complex length expressions and add test for such class (SmallOrderedHashSet). Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72148}
-
- 11 Nov, 2020 1 commit
-
-
Igor Sheludko authored
This CL * renames Name::hash_field field to raw_hash_field. * all local variables that store raw_hash_field value are also renamed to raw_hash_field where possible. Bug: chromium:1133527, v8:11074 Change-Id: I17313f386110b33a64f629cc2b9d4afd1e06c6c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471999Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71114}
-
- 21 Sep, 2020 1 commit
-
-
Z Nguyen-Huu authored
For js frame, we want to display currently executing function. Change-Id: If33b04279dafdf6e4834bfb6c7240e8e7e799fc7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2411483Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70018}
-
- 18 Jun, 2020 1 commit
-
-
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: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68407}
-
- 05 Jun, 2020 1 commit
-
-
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: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68211}
-
- 03 Jun, 2020 1 commit
-
-
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: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68137}
-
- 04 May, 2020 1 commit
-
-
Dan Elphick authored
Moves ReadOnlyPage, ReadOnlyArtifacts, ReadOnlySpace and SharedReadOnlySpace out of spaces.h and into read-only-spaces.h, as well as creating a corresponding .cc file. Bug: v8:10473 Change-Id: I9d8b49d61ed643fd6e16919d571a909ab6fce407 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2171197Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#67531}
-
- 09 Mar, 2020 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66633}
-
- 26 Feb, 2020 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66465}
-
- 19 Feb, 2020 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66349}
-
- 07 Feb, 2020 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66182}
-
- 23 Jan, 2020 1 commit
-
-
Seth Brenith authored
This change adds support for the postmortem inspection library to show the content of cached external strings if that content is available. It also fixes a minor annoyance where strings with unavailable data would show up as "...". Now, if fetching the very first character fails, we omit the literal value from the output. Bug: v8:9376 Change-Id: Id694a774c231ab3467fb59b1c149284729acfb20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987922Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65961}
-
- 07 Jan, 2020 1 commit
-
-
Seth Brenith authored
This change updates GetObjectProperties to list all of the bitfields within a class field, if that class field's type is a bitfield struct. The representation of bitfields in the GetObjectProperties response is very similar to the representation of struct fields, but with two extra bytes of data specifying the shift and size of the bitfield. Bug: v8:9376 Change-Id: I40a22169f3d01652a7f2db8cface43c2a1e30cfe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960835Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65610}
-
- 12 Dec, 2019 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65432}
-
- 26 Nov, 2019 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65183}
-
- 20 Nov, 2019 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65079}
-
- 16 Oct, 2019 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64331}
-
- 20 Sep, 2019 1 commit
-
-
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: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63908}
-
- 09 Sep, 2019 1 commit
-
-
Seth Brenith authored
v8_debug_helper attempts to flag known object pointers when it can recognize them, even if the memory pointed to is not available in the crash dump. In ptr-compr builds, the first pages of the map space, read-only space, and old space are always at the same offsets within the heap reservation region, so we can more easily detect known objects. Bug: v8:9376 Change-Id: I04e0d2357143d753f575f556e94f8fd42ce9d811 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783729 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63624}
-
- 30 Aug, 2019 1 commit
-
-
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: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63485}
-
- 22 Aug, 2019 1 commit
-
-
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: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#63352}
-
- 31 Jul, 2019 1 commit
-
-
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: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63008}
-
- 24 Jul, 2019 1 commit
-
-
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: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62899}
-
- 23 Jul, 2019 1 commit
-
-
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: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62882}
-