Skip to content

V
V8
Switch branch/tag
  1. 23 Aug, 2022 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Ensure all old-to-shared slots are recorded" · 4898cd54
      Dominik Inführ authored 
      This is a reland of commit c3a5c5b1

The previous CL was writing into the wrong sets when invoking
CollectSlots<OLD_TO_SHARED>(). Also move the NULL checks out of
that condition to also check this for chunks in the young generation.

Original change's description:
> [heap] Ensure all old-to-shared slots are recorded
>
> This CL adds verification of the old-to-shared remembered set to
> --verify-heap. During shared GCs client heaps will be scanned for
> references into the shared heap, this CL will CHECK that every found
> slot is contained in the old-to-shared remembered set. After this
> gets a bit more stable, the full heap iteration can be dropped and we
> can fully rely on the remembered set instead.
>
> Bug: v8:11708
> Change-Id: I0b5c4edfe3271306e4e7af7394472534113e1953
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792605
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82578}

Bug: v8:11708
Change-Id: I24b7787977f06708efb7a017dd1ec72f78d0ea13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3841570Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82653}
      4898cd54
  3. 19 Aug, 2022 2 commits
    • Nico Hartmann's avatar
      Revert "[heap] Ensure all old-to-shared slots are recorded" · cb9bf85b
      Nico Hartmann authored 
      This reverts commit c3a5c5b1.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20shared/21941/overview

Original change's description:
> [heap] Ensure all old-to-shared slots are recorded
>
> This CL adds verification of the old-to-shared remembered set to
> --verify-heap. During shared GCs client heaps will be scanned for
> references into the shared heap, this CL will CHECK that every found
> slot is contained in the old-to-shared remembered set. After this
> gets a bit more stable, the full heap iteration can be dropped and we
> can fully rely on the remembered set instead.
>
> Bug: v8:11708
> Change-Id: I0b5c4edfe3271306e4e7af7394472534113e1953
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792605
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82578}

Bug: v8:11708
Change-Id: I26553d3b06d0e257a3425eeb884ccce57f026bde
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3841567
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82580}
      cb9bf85b
    • Dominik Inführ's avatar
      [heap] Ensure all old-to-shared slots are recorded · c3a5c5b1
      Dominik Inführ authored 
      This CL adds verification of the old-to-shared remembered set to
--verify-heap. During shared GCs client heaps will be scanned for
references into the shared heap, this CL will CHECK that every found
slot is contained in the old-to-shared remembered set. After this
gets a bit more stable, the full heap iteration can be dropped and we
can fully rely on the remembered set instead.

Bug: v8:11708
Change-Id: I0b5c4edfe3271306e4e7af7394472534113e1953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792605Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82578}
      c3a5c5b1
  5. 13 Aug, 2022 1 commit
    • Omer Katz's avatar
      Reland "[heap] Use PagedNewSpace when MinorMC is enabled" · f5064ef9
      Omer Katz authored 
      This is a reland of commit 924be695

Original change's description:
> [heap] Use PagedNewSpace when MinorMC is enabled
>
> This CL also introduces/updates DCHECKs that some methods are never
> reached with MinorMC (they may still be reached by full GC when MinorMC
> is disabled).
>
> Bug: v8:12612
> Change-Id: I8afb8c964bc5c44225a92d0f8d9ac5a4c0ecef75
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3823130
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82439}

Bug: v8:12612
Change-Id: I64aa83d48fb48970ee45263356aaf1541e3d6bdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827040
Commit-Queue: Adam Klein <adamk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82448}
      f5064ef9
  7. 12 Aug, 2022 3 commits
  9. 11 Aug, 2022 1 commit
  11. 10 Aug, 2022 1 commit
  13. 08 Aug, 2022 2 commits
  15. 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
  17. 03 Jun, 2022 1 commit
  19. 19 May, 2022 1 commit
  21. 17 May, 2022 1 commit
  23. 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
  25. 13 May, 2022 1 commit
  27. 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
  29. 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
  31. 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
  33. 24 Feb, 2022 1 commit
  35. 23 Feb, 2022 3 commits
  37. 18 Feb, 2022 1 commit
  39. 17 Feb, 2022 1 commit
  41. 14 Feb, 2022 1 commit
  43. 11 Feb, 2022 2 commits
  45. 09 Feb, 2022 1 commit
  47. 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
  49. 12 Jan, 2022 1 commit
  51. 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
  53. 16 Nov, 2021 1 commit
  55. 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
  57. 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
  59. 09 Nov, 2021 1 commit
  61. 08 Nov, 2021 1 commit