Skip to content

V
V8
Switch branch/tag
  1. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored 
      This CL splits the class definitions per .tq file, to realize the
following relationship:
A class defined in src/objects/foo.tq has a C++ definition in
src/objects/foo.h. Torque then generates:

- torque-generated/src/objects/foo-tq.inc
  An include file (no proper header) to be included in src/objects/foo.h
  containing the Torque-generated C++ class definition.

- torque-generated/src/objects/foo-tq-inl.inc
  An include file (no proper header) to be included in
  src/objects/foo-inl.h containing inline function definitions.

- torque-generated/src/objects/foo-tq.cc
  A source file including src/objects/foo-inl.h that contains non-inline
  function definitions.

Advantages of this approach:
- Avoid big monolithic headers and preserve the work that went into
  splitting objects.h
- Moving a definition to Torque keeps everything in the same place
  from a C++ viewpoint, including a fully Torque-generated C++ class
  definition.
- The Torque-generated include files do not need to be independent
  headers, necessary includes or forward declarations can just be added
  to the headers that include them.

Drive-by changes:
A bunch of definitions and files had to be moved or created to realize
a consistent 1:1 relationship between .tq files and C++ headers.


Bug: v8:7793
TBR: hpayer@chromium.org
Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  3. 27 May, 2020 1 commit
  5. 11 May, 2020 1 commit
  7. 08 May, 2020 1 commit
  9. 18 Nov, 2019 1 commit
  11. 29 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [cleanup][torque] Use @generateCppClass in some simple cases, part 2 · a5811358
      Seth Brenith authored 
      This patch is mostly mechanical. A few changes in
implementation-visitor.cc might be worth mentioning:
- Don't generate both field offset macros and class definitions for the
  same class. This was mostly just to keep me from forgetting to remove
  the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but
  also helpfully flagged that FixedArrayBase wasn't using the generated
  class that it requested.
- Generate forward declarations for all tq-defined classes in
  internal-class-definitions-tq.h. This is helpful for making things
  compile when classes have fields of other class types.
- When generating accessors for union types, use the nearest class type
  that contains the entire union rather than plain Object. This is
  important for compile-time type safety. It also required a few minor
  fixes elsewhere (isolate.cc, modules.cc, scope-info.cc,
  source-text-module.cc, and a correction of the field types in
  CallHandlerInfo to match how they're set in api.cc).

Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63458}
      a5811358
  13. 03 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Remove some uses of @noVerifier · 29ec0087
      Seth Brenith authored 
      Implemented verifiers for the following classes:
- ExternalString
- FixedArrayBase
- JSCollection
- JSCollectionIterator
- JSWeakCollection
- Name
- SeqString
- Struct

Removed the following class definitions from Torque, because they're
just JSObject instances with particular starting maps, as discussed in
https://crrev.com/c/v8/v8/+/1619146/6/src/builtins/base.tq#459 :
- JSAccessorPropertyDescriptor
- JSDataPropertyDescriptor
- JSIteratorResult

Following similar logic, removed the Torque definition of
WasmExceptionPackage because it's just an error object that happens to
have a couple of private-symbol properties.

The following classes should not be defined in Torque because they're
just a starting state for JSObject, but I'm leaving them for now because
existing Torque code requires them:
- JSArgumentsObjectWithLength
- JSProxyRevocableResult

Bug: v8:9311
Change-Id: I0336b6be7d02e48e4a8a0f660e24d2c2fa5f5e34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1637448
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61970}
      29ec0087
  15. 23 May, 2019 1 commit
  17. 14 May, 2019 1 commit
    • Sigurd Schneider's avatar
      [torque] Introduce @abstract annotation for Torque classes · 4d05884e
      Sigurd Schneider authored 
      This annotation indicates that the class itself is not instantiated,
and does not have its own instance type: The instance types that
logically belong to the class are the instance types of the derived
classes.

Currently, we need the indication @dirtyInstantiatedAbstractClass
for several classes that are used as both, abstract base classes
and concrete classes. The prime example is JSObject which is the
base for many other classes, and also serves as the class to allocate
plain JSObjects. The annotation is purposefully ugly because in the
future we should refactor code to make it unnecessary.

Another annotation we introduce is @hasSameInstanceTypeAsParent,
which indicates another design pattern that currently occurs in the
code-base: Some Torque classes have the same instance types as their
parent class, but rename some fields, or possibly have a different map.
In such cases, the parent class is not abstract and the derived classes
can be seen as refinements of this class (that, for example, narrows the
type of a field). In the future, Torque should accomodate this pattern
better, but at moment we are content with just indicating where it is
used.

Bug: v8:7793
Change-Id: I1892dcc7325250df75d80308bf3d767d6d43bcc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607761
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61495}
      4d05884e
  19. 08 Apr, 2019 1 commit
    • Benedikt Meurer's avatar
      [heap] Various improvements to GC stats. · f8e3b1d6
      Benedikt Meurer authored 
      This CL contains a bunch of different improvements to the existing
object stats, namely:

 - Introduce DEPRECATED_DESCRIPTOR_ARRAY_TYPE virtual instance type to
   also estimate the memory overhead of DescriptorArrays for deprecated
   Maps.
 - Do proper over-allocation computating for inobject fields in JSObjects.
 - Introduce OBJECT_PROPERTY_ARRAY_TYPE virtual instance type and properly
   compute over-allocation for PropertyArrays
 - Compute over-allocation for JSObject/JSArray elements properly.
 - Correctly report JSFunction and JSCollection like the other
   JSObjects, specifically report over-allocation properly for the
   instances itself and for the elements/properties backing stores.
 - Implement correct over-allocation computation for hash tables in
   ObjectStatsCollectorImpl::RecordHashTableVirtualObjectStats().

Bug: v8:7266
Change-Id: I9cadd703266dc90911a8e7420c3b00dcee82b06d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1557139
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60683}
      f8e3b1d6
  21. 04 Apr, 2019 1 commit
  23. 29 Mar, 2019 1 commit
  25. 26 Mar, 2019 1 commit
  27. 08 Mar, 2019 1 commit
  29. 01 Mar, 2019 1 commit
  31. 27 Feb, 2019 1 commit
  33. 09 Jan, 2019 1 commit
  35. 26 Dec, 2018 1 commit
  37. 08 Dec, 2018 1 commit
  39. 22 Nov, 2018 1 commit
  41. 24 Oct, 2018 1 commit
  43. 17 Sep, 2018 1 commit
  45. 27 Jul, 2018 1 commit
  47. 12 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [cleanup] Remove Isolate parameter from object print · 13b899a5
      Leszek Swirski authored 
      With ReadOnlyRoots and GetIsolate on JSReceiver, we can remove almost
every isolate parameter from <Object>::Print. The remaining ones, like
Map, are special-caseable for read-only maps, and as a result we can
remove isolate parameters from <Object>::Print entirely.

This patch also opportunistically cleans up a few places where isolates
were only needed for Object::Print, such as TransitionAccessors and
DescriptorArrays.

TBR=yangguo@chromium.org,mstarzinger@chromium.org

Bug: v8:7786
Change-Id: Id44bd53b9893e679eea5f37b9548257595a1bfd9
Reviewed-on: https://chromium-review.googlesource.com/1133385Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54401}
      13b899a5
  49. 26 Jun, 2018 1 commit
  51. 20 Jun, 2018 1 commit
  53. 08 Jun, 2018 2 commits
  55. 07 Jun, 2018 2 commits
  57. 01 Dec, 2017 1 commit