Skip to content

V
V8
Switch branch/tag
  1. 07 Apr, 2022 1 commit
  3. 16 Feb, 2022 1 commit
  5. 04 Feb, 2022 2 commits
  7. 28 Jan, 2022 2 commits
  9. 27 Jan, 2022 2 commits
  11. 21 Jan, 2022 1 commit
  13. 20 Jan, 2022 1 commit
    • Nico Hartmann's avatar
      Revert "[Torque] Generalize Torque literals to larger size" · 362e265d
      Nico Hartmann authored 
      This reverts commit 757830b0.

Reason for revert: Speculatively revert due to a number of
performance regressions

Original change's description:
> [Torque] Generalize Torque literals to larger size
>
> Previously, literals in Torque were stored as double values, which
> made it impossible to precisely represent 64 bit integer values.
> This CL replaces the old literal expression with an integer and
> floating point literal expression that are unbounded in size. We
> allow implicit conversion of these literals to arbitary integer
> and floating point types respectively and insert a corresponding
> bounds check into generated CSA.
>
> Bug: v8:7793
> Change-Id: I46c231aab92bc2f0c26955d1876079f306b358c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329792
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78671}

Bug: v8:7793
Change-Id: I9896e28b3c69b8cf2488bf93e993ec320d8c5d2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401866Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78706}
      362e265d
  15. 18 Jan, 2022 1 commit
  17. 17 Jan, 2022 1 commit
  19. 14 Jan, 2022 1 commit
  21. 13 Jan, 2022 2 commits
  23. 14 Dec, 2021 1 commit
  25. 06 Dec, 2021 1 commit
  27. 01 Dec, 2021 1 commit
  29. 30 Nov, 2021 1 commit
  31. 29 Nov, 2021 1 commit
  33. 24 Nov, 2021 2 commits
  35. 11 Nov, 2021 1 commit
  37. 10 Nov, 2021 2 commits
  39. 09 Nov, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Clarify class annotations · 4dc59509
      Seth Brenith authored 
      As Nico pointed out in [1], it is a little strange that the pair of
annotations "@export @customCppClass" behaves similarly to the keyword
"extern": both indicate that the class is defined in a C++ file and
Torque generates only a base class template for it. In this change, I
explore a possible alternative which might be more consistent.

Removed annotations:
- @customCppClass, which required @export, instructed Torque to only
  generate a base class template instead of a full class.
- @customMap, which also required @export, instructed Torque to not emit
  code for setting up a unique Map instance for the class.

Added annotations:
- @generateUniqueMap, which requires extern, instructs Torque to emit
  code for setting up a unique Map instance for the class.
- @generateFactoryFunction, which requires extern, instructs Torque to
  emit a function for creating a class instance.

Subtracting two annotations and adding two others still leaves us with
way too many annotations, but the usage of "extern" becomes more
consistent and I think that the new opt-in annotations might be easier
to understand.

[1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit

Bug: v8:7793
Change-Id: Ic9e147a095bc492d6645001b9275357386e8adcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266008Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77799}
      4dc59509
  41. 05 Nov, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Get rid of `weak` keyword · 6745405f
      Seth Brenith authored 
      Torque allows a `weak` keyword on class field declarations. This keyword
is confusing, because it means two completely different things:

1. This field should be included in the weak fields section, meaning the
   field's offset should be in the range [kStartOfWeakFieldsOffset,
   kEndOfWeakFieldsOffset).
2. If a BodyDescriptor is generated for this class, then this field
   should be visited using *custom* weakness semantics
   (IterateCustomWeakPointers, not IterateMaybeObjectPointers).

I propose the following updated behavior, which I think is a bit more
reasonable:

1. To request that the generated BodyDescriptor use custom weakness
   semantics, use a new annotation @customWeakMarking.
2. The weak fields section includes all fields that can be a Weak<T>
   type, plus those annotated with @customWeakMarking.

These new rules require reordering fields in two classes which didn't
already have all of their strong fields adjacent.

Bug: v8:7793
Change-Id: Ic9d741986afa7fc1be3de044af5cae11a3c64d8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3261968
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77739}
      6745405f
  43. 03 Nov, 2021 2 commits
    • Nico Hartmann's avatar
      Revert "Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants"" · 6a3dc05f
      Nico Hartmann authored 
      This reverts commit a3480b55.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20header%20includes/22234/overview

Original change's description:
> Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants"
>
> This is a reland of 7366f6e2
>
> The test that failed after the initial commit was just flaky and has
> been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341
>
> Original change's description:
> > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
> >
> > Torque currently generates constants like kStartOfWeakFieldsOffset and
> > kEndOfStrongFieldsOffset, which can be used when writing custom
> > BodyDescriptors. However, these offsets have some potentially confusing
> > behaviors:
> >
> > * They don't take inheritance into account and describe only the fields
> >   defined by the current class itself, so there might be (for example)
> >   strong fields before kStartOfStrongFieldsOffset if they were defined
> >   by a superclass.
> > * kStartOfWeakFieldsOffset points to the first field defined in Torque
> >   using the keyword `weak`, which indicates fields with *custom*
> >   weakness semantics (those that should be visited with
> >   IterateCustomWeakPointers), not those that may contain standard weak
> >   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
> >   like to also rename `weak` to `@customWeak`.)
> >
> > Given that these constants have very low usage and somewhat bizarre
> > semantics, I propose that we remove them. This change does so, and
> > updates the existing usages to either define the required constants
> > directly in C++ or not use them. I know that defining these constants in
> > C++ is more brittle, but I think that brittle and clear is better than
> > automatic and incomprehensible.
> >
> > Bug: v8:7793
> > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Cr-Commit-Position: refs/heads/main@{#77411}
>
> Bug: v8:7793
> Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77688}

Bug: v8:7793
Change-Id: I7b9667268901b7aef85a95832d40860056e61050
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259656Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77689}
      6a3dc05f
    • Seth Brenith's avatar
      Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants" · a3480b55
      Seth Brenith authored 
      This is a reland of 7366f6e2

The test that failed after the initial commit was just flaky and has
been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341

Original change's description:
> [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
>
> Torque currently generates constants like kStartOfWeakFieldsOffset and
> kEndOfStrongFieldsOffset, which can be used when writing custom
> BodyDescriptors. However, these offsets have some potentially confusing
> behaviors:
>
> * They don't take inheritance into account and describe only the fields
>   defined by the current class itself, so there might be (for example)
>   strong fields before kStartOfStrongFieldsOffset if they were defined
>   by a superclass.
> * kStartOfWeakFieldsOffset points to the first field defined in Torque
>   using the keyword `weak`, which indicates fields with *custom*
>   weakness semantics (those that should be visited with
>   IterateCustomWeakPointers), not those that may contain standard weak
>   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
>   like to also rename `weak` to `@customWeak`.)
>
> Given that these constants have very low usage and somewhat bizarre
> semantics, I propose that we remove them. This change does so, and
> updates the existing usages to either define the required constants
> directly in C++ or not use them. I know that defining these constants in
> C++ is more brittle, but I think that brittle and clear is better than
> automatic and incomprehensible.
>
> Bug: v8:7793
> Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77411}

Bug: v8:7793
Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77688}
      a3480b55
  45. 02 Nov, 2021 1 commit
  47. 28 Oct, 2021 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] extend type asserts to cover all JS types" · 392078fb
      Tobias Tebbi authored 
      This is a reland of 45227ffd
Differences:
- Handle one more flags conflict in variants.py.
- Disallow %VerifyType without --concurrent-recompilation.

Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
>    OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
>    HeapConstant Factory::zero_string(). However, NumberToString does
>    not always produce this string. To avoid regressions, the CL keeps
>    the HeapConstant type and changes the runtime and builtin code to
>    always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}

Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77596}
      392078fb
  49. 27 Oct, 2021 2 commits
    • Maya Lekova's avatar
      Revert "[turbofan] extend type asserts to cover all JS types" · 54f90462
      Maya Lekova authored 
      This reverts commit 45227ffd.

Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview

Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
>    OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
>    HeapConstant Factory::zero_string(). However, NumberToString does
>    not always produce this string. To avoid regressions, the CL keeps
>    the HeapConstant type and changes the runtime and builtin code to
>    always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}

Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@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/main@{#77566}
      54f90462
    • Tobias Tebbi's avatar
      [turbofan] extend type asserts to cover all JS types · 45227ffd
      Tobias Tebbi authored 
      Extend type assertions to all types covering JavaScript values.
This is achieved by allocating type representations on the heap using
newly defined HeapObject subclasses. To allocate these in the compiler,
we disable concurrent compilation for the --assert-types flag for now.

Fix two type errors that came up with the existing tests:
1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
   OtherObject.
2. OperationTyper::NumberToString(Type) can type the result as the
   HeapConstant Factory::zero_string(). However, NumberToString does
   not always produce this string. To avoid regressions, the CL keeps
   the HeapConstant type and changes the runtime and builtin code to
   always produce the canonical "0" string.

A few tests were failing because they check for truncations to work
and prevent deoptimization. However, AssertType nodes destroy all
truncations (which is by design), so these tests are incompatible
and now disabled for the assert_types variant.

Drive-by fix: a few minor Torque issues that came up.

Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77565}
      45227ffd
  51. 20 Oct, 2021 1 commit
  53. 15 Oct, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants" · 6025b260
      Leszek Swirski authored 
      This reverts commit 7366f6e2.

Reason for revert: Speculative revert for cctest/test-debug-helper/GetObjectProperties failures
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8833300564873660401/+/u/Check/GetObjectProperties

Original change's description:
> [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants
>
> Torque currently generates constants like kStartOfWeakFieldsOffset and
> kEndOfStrongFieldsOffset, which can be used when writing custom
> BodyDescriptors. However, these offsets have some potentially confusing
> behaviors:
>
> * They don't take inheritance into account and describe only the fields
>   defined by the current class itself, so there might be (for example)
>   strong fields before kStartOfStrongFieldsOffset if they were defined
>   by a superclass.
> * kStartOfWeakFieldsOffset points to the first field defined in Torque
>   using the keyword `weak`, which indicates fields with *custom*
>   weakness semantics (those that should be visited with
>   IterateCustomWeakPointers), not those that may contain standard weak
>   pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
>   like to also rename `weak` to `@customWeak`.)
>
> Given that these constants have very low usage and somewhat bizarre
> semantics, I propose that we remove them. This change does so, and
> updates the existing usages to either define the required constants
> directly in C++ or not use them. I know that defining these constants in
> C++ is more brittle, but I think that brittle and clear is better than
> automatic and incomprehensible.
>
> Bug: v8:7793
> Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#77411}

Bug: v8:7793
Change-Id: Ia12b5d773db35739283ca8871d3dd6922413cc82
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226783
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77415}
      6025b260
    • Seth Brenith's avatar
      [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants · 7366f6e2
      Seth Brenith authored 
      Torque currently generates constants like kStartOfWeakFieldsOffset and
kEndOfStrongFieldsOffset, which can be used when writing custom
BodyDescriptors. However, these offsets have some potentially confusing
behaviors:

* They don't take inheritance into account and describe only the fields
  defined by the current class itself, so there might be (for example)
  strong fields before kStartOfStrongFieldsOffset if they were defined
  by a superclass.
* kStartOfWeakFieldsOffset points to the first field defined in Torque
  using the keyword `weak`, which indicates fields with *custom*
  weakness semantics (those that should be visited with
  IterateCustomWeakPointers), not those that may contain standard weak
  pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd
  like to also rename `weak` to `@customWeak`.)

Given that these constants have very low usage and somewhat bizarre
semantics, I propose that we remove them. This change does so, and
updates the existing usages to either define the required constants
directly in C++ or not use them. I know that defining these constants in
C++ is more brittle, but I think that brittle and clear is better than
automatic and incomprehensible.

Bug: v8:7793
Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77411}
      7366f6e2
  55. 13 Oct, 2021 1 commit
  57. 12 Oct, 2021 1 commit
  59. 08 Oct, 2021 1 commit
  61. 06 Oct, 2021 1 commit