1. 05 Sep, 2022 3 commits
  2. 01 Sep, 2022 2 commits
  3. 25 Aug, 2022 1 commit
  4. 22 Aug, 2022 2 commits
  5. 09 Aug, 2022 1 commit
  6. 01 Aug, 2022 1 commit
  7. 26 Jul, 2022 2 commits
    • Leon Bettscheider's avatar
      [heap] YoungGenerationConcurrentMarkingVisitor · 55a497d9
      Leon Bettscheider authored
      Similar to the FullGC marking hierarchy (MarkingVisitorBase, with
      derived classes MainMarkingVisitor and ConcurrentMarkingVisitor),
      this CL introduces YoungGenerationMarkingVisitorBase +
      YoungGenerationConcurrentMarkingVisitor, and refactors
      YoungGenerationMarkingVisitor to inherit from
      YoungGenerationMarkingVisitorBase.
      
      YoungGenerationConcurrentMarkingVisitor dispatches to functions
      refactored to ConcurrentMarkingVisitorUtility by the previous CL.
      
      Bug: v8:13012
      Change-Id: I0e827eb95732ed9ddf027fe68e25a0839cdda773
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780524Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Leon Bettscheider <bettscheider@google.com>
      Cr-Commit-Position: refs/heads/main@{#81976}
      55a497d9
    • Leon Bettscheider's avatar
      Reland "[heap] Refactor methods and nested class of ConcurrentMarkingVisitor" · 4d07e0bf
      Leon Bettscheider authored
      This is a reland of commit 6925bc09
      
      Original change's description:
      > [heap] Refactor methods and nested class of ConcurrentMarkingVisitor
      >
      > This CL moves a few methods and nested class SlotSnapshottingVisitor
      > from ConcurrentMarkingVisitor to ConcurrentMarkingVisitorUtility.
      >
      > Methods in ConcurrentMarkingVisitorUtility are now static and instead have a Visitor parameter.
      >
      > This is preparatory work for adding a
      > YoungGenerationConcurrentMarkingVisitor class, which will be able to
      > reuse members of ConcurrentMarkingVisitorUtility.
      >
      > Bug: v8:13012
      > Change-Id: I503c20e655578031018a2e37dd92c1d61bbe1686
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779677
      > Commit-Queue: Leon Bettscheider <bettscheider@google.com>
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#81931}
      
      Bug: v8:13012
      Change-Id: I05063263d831ef4f3e297289e4210850029f7607
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3780500Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Leon Bettscheider <bettscheider@google.com>
      Cr-Commit-Position: refs/heads/main@{#81953}
      4d07e0bf
  8. 25 Jul, 2022 2 commits
  9. 14 Jul, 2022 1 commit
  10. 11 Jul, 2022 1 commit
  11. 30 Jun, 2022 1 commit
  12. 01 Jun, 2022 1 commit
  13. 23 May, 2022 1 commit
  14. 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
  15. 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
  16. 13 Apr, 2022 1 commit
    • Nikolaos Papaspyrou's avatar
      heap: Inline GCTracer::Scope constructor and destructor · ae0480a0
      Nikolaos Papaspyrou authored
      Tracer scopes are used in numerous places in src/heap to track time
      spent during various phases of the garbage collection. Usually, they
      are introduced with the TRACE_GC* family of macros, taking the scope
      identifier as a parameter. At most call sites, the scope identifier is
      known at compile time.
      
      This CL inlines the constructor and destructor of GCTracer::Scope, in
      order to enable the C++ compiler to properly optimize the introduction
      of such scopes when the scope identifier is known at compile time,
      using constant propagation. This is expected to have a performance
      impact for short-lived and frequently used scopes, e.g., in incremental
      marking and sweeping steps.
      
      Change-Id: I6f1a2954a437de1fa6dab5e464c20c952d84ffd4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581774Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79957}
      ae0480a0
  17. 14 Mar, 2022 1 commit
  18. 20 Jan, 2022 1 commit
  19. 13 Jan, 2022 2 commits
    • Leszek Swirski's avatar
      Revert "cppgc-js,heap: Implement snapshots for embedder fields" · 7d4e3d35
      Leszek Swirski authored
      This reverts commit 142dd775.
      
      Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview
      
      Original change's description:
      > cppgc-js,heap: Implement snapshots for embedder fields
      >
      > https://crrev.com/c/3293410 added concurrent processing of C++ objects
      > found through V8 embedder fields. The CL missed that those embedder
      > fields are not read atomically from JS objects. The problem is that
      > embedder fields are only aligned to kTaggedSize on builds with pointer
      > compression and are as such mis-aligned for atomic ops. This is not a
      > problem for on-heap values as the upper 32bits are anyways computed
      > from the cage. Is is a problem for generic C++ values though, as they
      > are used with Oilpan.
      >
      > This CL adds the standard marker snapshot protocol for embedder fields.
      >
      > Marker:
      > 1. Snapshot embedder fields
      > 2. Try to mark host object
      > 3. On success: process snapshot
      >
      > Main thread:
      > 1. On setting embedder fields mark the object black first
      > 2. Emit a write barrier for the embedder fields
      >
      > This will get simpler with the heap sandbox that uses a separate table
      > for embedder fields. Once the sandbox is the default configuration, we
      > 	can use it as dependency for the concurrent fast path.
      >
      > Bug: chromium:1285706
      > Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78604}
      
      Bug: chromium:1285706
      Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@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@{#78605}
      7d4e3d35
    • Michael Lippautz's avatar
      cppgc-js,heap: Implement snapshots for embedder fields · 142dd775
      Michael Lippautz authored
      https://crrev.com/c/3293410 added concurrent processing of C++ objects
      found through V8 embedder fields. The CL missed that those embedder
      fields are not read atomically from JS objects. The problem is that
      embedder fields are only aligned to kTaggedSize on builds with pointer
      compression and are as such mis-aligned for atomic ops. This is not a
      problem for on-heap values as the upper 32bits are anyways computed
      from the cage. Is is a problem for generic C++ values though, as they
      are used with Oilpan.
      
      This CL adds the standard marker snapshot protocol for embedder fields.
      
      Marker:
      1. Snapshot embedder fields
      2. Try to mark host object
      3. On success: process snapshot
      
      Main thread:
      1. On setting embedder fields mark the object black first
      2. Emit a write barrier for the embedder fields
      
      This will get simpler with the heap sandbox that uses a separate table
      for embedder fields. Once the sandbox is the default configuration, we
      	can use it as dependency for the concurrent fast path.
      
      Bug: chromium:1285706
      Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78604}
      142dd775
  20. 27 Dec, 2021 1 commit
    • Omer Katz's avatar
      cppgc-js, heap: Concurrently push references from v8 to Oilpan · d10f61e1
      Omer Katz authored
      Included in this CL:
      (*) Introduce CppMarkingState that V8 should use to push references to
          Oilpan. CppMarkingState allocates its own Worklist::Locals to
          support concurrent updates from V8.
      (*) Split Oilpan MarkingWorklist object to form a base class used by
          CppMarkingState.
      (*) Remove MarkerFactory and split marking initialization. Marking
          worklists should already be initialized when V8 initializes
          visitors. For incremental marking, this requires splitting
          marking initialization and marking start.
      (*) Drive-by: Mark JSObject::IsApiWrapper and
          JSObject::IsDroppableApiWrapper as const.
      
      Bug: v8:12407
      Change-Id: I35cc816343da86f69a68306204675720e9b3913f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293410Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78446}
      d10f61e1
  21. 08 Dec, 2021 1 commit
  22. 06 Dec, 2021 1 commit
  23. 02 Dec, 2021 1 commit
  24. 30 Nov, 2021 2 commits
  25. 26 Nov, 2021 1 commit
  26. 25 Nov, 2021 1 commit
    • Dominik Inführ's avatar
      [heap] Fix accounting for left-trimmed arrays · 956d32e3
      Dominik Inführ authored
      ShouldVisit() uses obj.Size() to increment the live bytes counter after
      the object was successfully marked grey. However, this re-reads the
      length field which could have already been overwritten by a
      concurrent left-trimming operation on the main thread. Fix this by
      calculating the object size later with the length field we read before
      marking that object black. That value is guaranteed to be a SMI.
      
      Bug: chromium:1273352
      Change-Id: I47e5a2df3eef61b4ef07af943f30123e5c2f7f9d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302793
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78093}
      956d32e3
  27. 14 Oct, 2021 1 commit
  28. 08 Oct, 2021 1 commit
  29. 28 Sep, 2021 2 commits
    • Dominik Inführ's avatar
      [heap] Improve ephemeron processing · 1054ee7f
      Dominik Inführ authored
      Refactor code such that the linear algorithm is actually executed
      outside the method for the fixpoint iteration. Also added a CHECK
      which verifies that iterating the ephemerons one more time results in
      no further marked objects.
      
      Also force another iteration when ProcessMarkingWorklist() processed
      some object. In such cases we need to re-process all ephemerons
      otherwise ephemeron semantics might be broken.
      
      Bug: chromium:1252918
      Change-Id: I9123dda50e34227a04825fd8b3172368286cc76f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190100
      Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77131}
      1054ee7f
    • Seth Brenith's avatar
      [heap] Don't age bytecode when GCing for devtools snapshot · 4b532343
      Seth Brenith authored
      When preparing to take a heap snapshot for the devtools, V8 uses
      CollectAllAvailableGarbage, which runs 2 to 7 rounds of garbage
      collection, depending on whether weak callbacks indicate that further
      rounds might be beneficial. Depending on how many rounds of GC run,
      varying amounts of bytecode and baseline code may be flushed, leading to
      inconsistent behavior and underreporting the amount of memory used by
      bytecode and baseline code. In this change, I propose that bytecode
      should not increase in age during these collections, so that the
      resulting snapshot is a better indication of actual memory usage.
      
      Change-Id: I644be37833f85bb58e2e2fad5da62949cbdc9bef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3182885Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77122}
      4b532343
  30. 27 Sep, 2021 1 commit