Skip to content

V
V8
Switch branch/tag
  1. 09 Jun, 2022 1 commit
    • Dominik Inführ's avatar
      [heap] Track unprotected chunks in LocalHeap · a537be46
      Dominik Inführ authored 
      CodePageCollectionMemoryModificationScope now increases a per-thread
counter and inserts unprotected code chunks into a thread-local set
of chunks. This information is moved from Heap into LocalHeap.

We can't use kMaxWriteUnprotectCounter on the unprotect counter on the
MemoryChunk anymore, since e.g. for concurrent Sparkplug N threads might
now allocate a code object on the same page and since
CodePageCollectionMemoryModificationScope doesn't know about the
other threads anymore, each thread has to increase that counter by 1.
We DCHECK that nesting depth now in the scope's constructor instead.

We still need to remove chunks from `unprotected_memory_chunks_` when
freeing an executable MemoryChunk during GC. Fortunately we can still do
this, since all threads are in a safepoint during GC and we can remove
the chunk from each thread-local set without any synchronization.

Bug: chromium:1330887
Change-Id: Icefc61b8d8de113d8dcfb1cf64122d12dd9798c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688516Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81047}
      a537be46
  3. 03 Jun, 2022 1 commit
  5. 19 May, 2022 1 commit
  7. 17 May, 2022 1 commit
  9. 16 May, 2022 1 commit
    • Omer Katz's avatar
      [heap] Merge original_top/limit from NewSpace and PagedSpace · a8656e55
      Omer Katz authored 
      SpaceWithLinearArea will holds a ref to a struct containing
original_top_ and original_limit_ as well the lock used to sync them
for querying IsPendingAllocation.

PagedSpace is split into PagedSpaceBase (that holds all funcitonality)
and PagedSpace. The actual fields are owned by PagedSpace and NewSpace.

This is done in preparation for PagedNewSpace to allow PagedSpaceiBase
and NewSpace to share the same original_top_ and original_limit_ fields.

Bug: v8:12612
Change-Id: Iefbbd5209c5553db4ee16cb261734e6479e0f23f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644795
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80549}
      a8656e55
  11. 13 May, 2022 1 commit
  13. 12 May, 2022 1 commit
    • Omer Katz's avatar
      [heap] Extend and rename NewSpace base class · b415cd7c
      Omer Katz authored 
      NewSpace is renamed to SemiSpaceNewSpace and NewSpaceBase is renamed to
NewSpace (the new PagedSpace new space implementation will be named
PagedNewSpace).

Most usecases are updated to use the base class rather than the concrete
semi space based implementation. To that end, the base class is extended
with additional virtual methods (for delegating to the concrete class).

This CL follows these guidelines:
(*) If at a method callsite we should know the exact new space
implementation we use, we cast to the concrete class. This is the case
for example for callsites in scavenger.*.
(*) If a method is called from outside the heap implementation or should
be present regardless of the concrete implementation, that method is
made virtual.
(*) Other cases are usually methods that are specific to a concrete
implementation but the concrete implementation is not known at the
callsite and there's no clear way to nicely abstract the method. In such
cases we cast to the concrete SemiSpaceNewSpace implementation for now
and we will revisit these cases once PagedNewSpace exists.

Bug: v8:12612
Change-Id: I7b85626774ce0d785b0257bf8d32b9f50eeaf292
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625975
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80482}
      b415cd7c
  15. 28 Apr, 2022 1 commit
    • Igor Sheludko's avatar
      Reland "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 449ece38
      Igor Sheludko authored 
      This is a reland of commit 9d31f866
There were issues with --future flag implications on M1.

Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
>    whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
>    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
>    to change them,
> 3) the request to set RWX permissions in the executable page region
>    just recommits the pages without changing permissions (see (1), they
>    were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
>    OS::DiscardSystemPages() instead of OS::DecommitPages() or
>    setting permissions to kNoAccess because the latter two are not
>    allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
>    necessary to switch between W^X modes when updating the data in the
>    page headers (i.e. when marking, updating stats, wiring pages in
>    lists, etc.). The new CodePageHeaderModificationScope class is used
>    in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
>    which is too expensive,
> b) in case of shared pointer compression cage if the code range will
>    be deleted while the cage is still alive then attempt to configure
>    permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}

Bug: v8:12797
Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80259}
      449ece38
  17. 27 Apr, 2022 2 commits
    • Adam Klein's avatar
      Revert "[rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)" · 10807c9f
      Adam Klein authored 
      This reverts commit 9d31f866.

Reason for revert: crashes on Mac/arm64 bots:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug/5923/overview

Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
>    whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
>    MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
>    to change them,
> 3) the request to set RWX permissions in the executable page region
>    just recommits the pages without changing permissions (see (1), they
>    were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
>    OS::DiscardSystemPages() instead of OS::DecommitPages() or
>    setting permissions to kNoAccess because the latter two are not
>    allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
>    necessary to switch between W^X modes when updating the data in the
>    page headers (i.e. when marking, updating stats, wiring pages in
>    lists, etc.). The new CodePageHeaderModificationScope class is used
>    in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
>    which is too expensive,
> b) in case of shared pointer compression cage if the code range will
>    be deleted while the cage is still alive then attempt to configure
>    permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}

Bug: v8:12797
Change-Id: Ic07948e036db36326d464a2a901d052aa060a406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611665
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80239}
      10807c9f
    • Igor Sheludko's avatar
      [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1) · 9d31f866
      Igor Sheludko authored 
      ... for V8 code space. The feature is currently disabled.

In order to use fast W^X permission switching we must allocate
executable pages with readable writable executable permissions (RWX).
However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
permission changing of RWX memory pages. This means that the code page
headers must be allocated with RWX permissions too because otherwise
it wouldn't be possible to allocate a large code page over the freed
regular code page and vice versa.

When enabled, the new machinery works as follows:

1) when memory region is reserved for allocating executable pages, the
   whole region is committed with RWX permissions and then decommitted,
2) since reconfiguration of RWX page permissions is not allowed on
   MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
   to change them,
3) the request to set RWX permissions in the executable page region
   just recommits the pages without changing permissions (see (1), they
   were already allocated as RWX and then discarded),
4) in order to make executable pages inaccessible one must use
   OS::DiscardSystemPages() instead of OS::DecommitPages() or
   setting permissions to kNoAccess because the latter two are not
   allowed by the MacOS (see (2)).
5) since code space page headers are allocated as RWX pages it's also
   necessary to switch between W^X modes when updating the data in the
   page headers (i.e. when marking, updating stats, wiring pages in
   lists, etc.). The new CodePageHeaderModificationScope class is used
   in the respective places. On unrelated configurations it's a no-op.

The fast permission switching can't be used for V8 configuration with
enabled pointer compression and disabled external code space because
a) the pointer compression cage has to be reserved with MAP_JIT flag
   which is too expensive,
b) in case of shared pointer compression cage if the code range will
   be deleted while the cage is still alive then attempt to configure
   permissions of pages that were previously set to RWX will fail.

This also CL extends the unmapper unit tests with permissions tracking
for discarded pages.

Bug: v8:12797
Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80238}
      9d31f866
  19. 24 Feb, 2022 1 commit
  21. 23 Feb, 2022 3 commits
  23. 18 Feb, 2022 1 commit
  25. 17 Feb, 2022 1 commit
  27. 14 Feb, 2022 1 commit
  29. 11 Feb, 2022 2 commits
  31. 09 Feb, 2022 1 commit
  33. 26 Jan, 2022 1 commit
    • Igor Sheludko's avatar
      [ext-code-space] Fix CodeRange allocation logic · 695afbff
      Igor Sheludko authored 
      1) when generating short builtin calls/jumps assemblers should use the
   offset from the CodeRange base rather than the start of the code
   range reservation because otherwise it's not guaranteed that the
   PC-relative offset will fit into architecture's constraints.
   The code range reservation start could be different from the code
   range base in the following cases:
     * when the "base bias size" is non-zero (on Windows 64),
     * when we ended up over-reserving the address space for the code
       range, which happens as a last resort to fulfil the CodeRange
       alignment requirements.
   See the VirtualMemoryCage description for details.

Drive-by fixes:
2) in case of over-reserving address space for external code range,
   the pre-calculated hint for where the remapped embedded builtins
   should be copied to was outside of the allocatable CodeRange region
   and thus useless. The fix is to use the allocatable region instead
   of the reservation region when calculating the hint.
3) when allocating CodeRange with zero base bias size we can create
   the VirtualMemory reservation from the first attempt simply by
   passing the required base alignment to the VirtualMemory
   constructor.

Bug: v8:11880, chromium:1290591
Change-Id: If341418947e2170d967e22b38bcc371594939c1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412089Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78772}
      695afbff
  35. 12 Jan, 2022 1 commit
  37. 22 Nov, 2021 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Support multiple clients in shared GC" · 2c88cec4
      Dominik Inführ authored 
      This is a reland of 90a9d6cb

The original CL got reverted because of two different issues:

* The DCHECK failure on AllowGarbageCollection::IsAllowed() got fixed
  in https://crrev.com/c/3289625.
* The crash with the incremental marking job were because of a nested
  GC started from a SafepointScope. This CL adds IgnoreLocalGCRequests
  scopes to SafepointScopes in src/heap.

In addition this CL prevents shared GCs during isolate deserialization
by locking the clients_mutex_ until the isolate is fully deserialized.
The original GC used a DisallowSafepoints scope to prevent shared GCs
from interrupting isolate deserialization.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

Bug: v8:11708, v8:12375, v8:12377
Change-Id: I9d1af6fbc06a3a8b6f216ec5e9027665ad071809
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283067
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78013}
      2c88cec4
  39. 16 Nov, 2021 1 commit
  41. 11 Nov, 2021 2 commits
    • Victor Gomes's avatar
      [heap] Remove code space depth check in CodePageCol**Scope · 553815a5
      Victor Gomes authored 
      The check is a simple shortcut, but this is not safe in multithreading.

In a multi-threaded situation, if a CodePageCol**Scope is open while
a CodeSpaceMem**Scope is already opened, the result is a noop.
If the latter finishes first, then we would decrement a wrong
depth in ~CodePageCollectionMemoryModificationScope.

Bug: v8:12054
Change-Id: I7e1016628ffbd37b343ea130eb8d7d8e60abec98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275562Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77849}
      553815a5
    • Dominik Inführ's avatar
      Revert "[heap] Support multiple clients in shared GC" · 2f98fb28
      Dominik Inführ authored 
      This reverts commit 90a9d6cb.

Reason for revert: Seems to make some test to fail flakily. Revert for now until this is fixed.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:11708
Change-Id: I85fbf896c59492fc571b3bfaa7f9e3ea8a883260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275552
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77845}
      2f98fb28
  43. 10 Nov, 2021 1 commit
    • Dominik Inführ's avatar
      [heap] Support multiple clients in shared GC · 90a9d6cb
      Dominik Inführ authored 
      Add support for safepointing multiple isolates as described in the
design doc (link is below). A safepoint across multiple isolates is
considered a global safepoint to distinguish it from regular safepoints.

The basic idea behind the implementation is that we reach a
safepoint for each client. What's new is that now also main threads
need to participate in the safepointing protocol and need to give up
control in time. The slow paths of Park(), Unpark() and Safepoint() on
the main thread need to be adjusted for this reason as well.

This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
IsolateSafepoint and IsolateSafepointScope.

This CL adds the type IgnoreLocalGCRequests, it is used to prevent
Park() and Unpark() from honoring the request from background threads
to perform a local GC. This is used heap-internally to not have GCs
(or even nested GCs) in certain locations. E.g. when initiating a
safepoint to perform a GC we don't want a "recursive" GC to occur.

Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing

Bug: v8:11708
Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77812}
      90a9d6cb
  45. 09 Nov, 2021 1 commit
  47. 08 Nov, 2021 3 commits
  49. 05 Nov, 2021 1 commit
  51. 27 Oct, 2021 1 commit
  53. 20 Oct, 2021 1 commit
  55. 11 Oct, 2021 1 commit
  57. 27 Sep, 2021 1 commit
  59. 23 Sep, 2021 1 commit
  61. 05 Aug, 2021 1 commit
    • Mythri A's avatar
      [sparkplug] Update DCHECK to work with fuzzers · dae3e24b
      Mythri A authored 
      There was a DCHECK to ensure tests don't miss enabling either bytecode
or baseline code flushing along with stress-flush-code. Fuzzers use
different combination of flags so there we should allow
stress-flush-code without bytecode / baseline code flushing.

Bug: chromium:1236614,v8:11947
Change-Id: I86190b6336015e37288cffffc05de2fa21f496ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074462
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76115}
      dae3e24b
  63. 04 Aug, 2021 1 commit
  65. 02 Aug, 2021 1 commit