- 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}
-
- 09 Mar, 2021 1 commit
-
-
Seth Brenith authored
The generated Torque files class-verifiers.cc and class-debug-readers.cc currently include files which are part of v8_initializers, despite being used in unrelated build targets. This change removes the unnecessary inclusions. There is still a lot of code included via all-objects-inl.h, but that's because these files require full class definitions for every object type. Bug: v8:11528 Change-Id: Ib26496f2a30ef576f1101636e0aca2cafbfd1f37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2743087 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#73301}
-
- 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}
-
- 25 Sep, 2020 1 commit
-
-
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:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
-
- 22 Sep, 2020 2 commits
-
-
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:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70065}
-
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:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70060}
-
- 22 Apr, 2020 1 commit
-
-
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:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67305}
-
- 21 Apr, 2020 2 commits
-
-
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:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67291}
-
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:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67290}
-
- 18 Mar, 2020 1 commit
-
-
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:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66759}
-
- 09 Mar, 2020 2 commits
-
-
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}
-
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:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66621}
-
- 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 fixes an issue found by the upcoming change that verifies a match between 32-bit Torque output from a 32-bit build and 32-bit output from a 64-bit build: https://crrev.com/c/v8/v8/+/1998078 . 32-bit output never needs to deal with pointer compression. Bug: v8:10124 Change-Id: I0e04728dafc4118a8816a3afa98651dddea7a574 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2001460Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65962}
-
- 16 Jan, 2020 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: I4fc039711eb9aa9d551144ea6fccc926d4803349 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993290 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65808}
-
- 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}
-
- 20 Dec, 2019 1 commit
-
-
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:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65538}
-
- 12 Dec, 2019 1 commit
-
-
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:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65427}
-
- 06 Dec, 2019 1 commit
-
-
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:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#65371}
-
- 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}
-
- 18 Nov, 2019 1 commit
-
-
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:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65016}
-
- 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}
-
- 14 Oct, 2019 1 commit
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: Id2e03e7d42aeab155572fa9cc3093dcff16f5668 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859622Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64274}
-
- 11 Oct, 2019 1 commit
-
-
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:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
-
- 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}
-
- 10 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
Since we switched to C++14 now, we can use {std::make_unique} instead of our own {base::make_unique} from {template-utils.h}. R=mstarzinger@chromium.org, yangguo@chromium.org Bug: v8:9687 No-Try: true Change-Id: I660eb30038bbb079cee93c7861cd87ccd134f01b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789300 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63642}
-
- 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}
-