Skip to content

V
V8
Switch branch/tag
  1. 05 Nov, 2021 11 commits
  3. 04 Nov, 2021 23 commits
  5. 03 Nov, 2021 6 commits
    • Anton Bikineev's avatar
      cppgc: Force EBO to always work with GCed · 92eae6d1
      Anton Bikineev authored 
      Currently, in the following struct

struct LayoutObject : GarbageCollected<>, MixinA, MixinB {};

the subobject that corresponds to the first base GarbageCollected<>
always takes up some space (one word). The empty-base-optimization
doesn't happen because the second base (MixinA) has the same subobject
as the first base (GarbageCollected), which is the most parent class
GarbageCollectedBase. The compiler can't "merge" them because it must
guarantee that distinct objects of the same type have distinct
addresses.

The attribute [[no_unique_address]] doesn't work for base classes,
unfortunately (but is a good idea for a Standard proposal). As a
solution, the CL simply removes GarbageCollectedBase.

Bug: chromium:1260797
Change-Id: I415b10a5fbcebce3d6ee97b8870ea9ae90f383a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259654
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77693}
      92eae6d1
    • Dominik Inführ's avatar
      [heap, objects] NativeContext::retained_maps might be uninitialized · 45adcb7c
      Dominik Inführ authored 
      When a GC happens during context deserialization,
NativeContext::retained_maps might be uninitialized and not store a
WeakArrayList but Smi 0.

Bug: v8:12198
Change-Id: I03c1dfaa013c47907af67bb13b9277d67ca5ffae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259662Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77692}
      45adcb7c
    • Milad Fa's avatar
      PPC/s390: Increase the number of args supported by the simulator to 20 · 344a4525
      Milad Fa authored 
      Port 4de20cb1

Original Commit Message:

    This CL adds a minor change to the arm/arm64 simulators to support up to
    20 arguments in a C function call. This change is necessary for an
    upcoming CL which adds float support to the simulator and tests with
    more than 20 arguments, see
    https://chromium-review.googlesource.com/c/v8/v8/+/3060486

R=mslekova@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: Ic3dabdcaa4982840466190003c56cfe82e91316b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259652Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77691}
      344a4525
    • Frank Tang's avatar
      [test262] Roll test262 · 2732cdb3
      Frank Tang authored 
      https://chromium.googlesource.com/external/github.com/tc39/test262/+log/ba82d462..42e21582f

Bug: v8:7834
Change-Id: Icaa556ec606908fb8c0cd110285e054e9f6b0254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258874Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77690}
      2732cdb3
    • 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