1. 11 Nov, 2021 1 commit
    • 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
  2. 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
  3. 22 Jul, 2021 1 commit
  4. 14 Jun, 2021 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Introduce ParkedSharedMutexGuardIf and use it in compiler" · e9c4ff40
      Dominik Inführ authored
      This is a reland of 4cd856ee
      
      This CL fixes the problem that local_isolate() returned nullptr on
      the main thread.
      
      Original change's description:
      > [heap] Introduce ParkedSharedMutexGuardIf and use it in compiler
      >
      > In some cases it could happen that the concurrent compiler tries to get
      > a shared lock on a mutex that is already exclusively held by the main
      > thread. The background thread will then block itself until the
      > main thread leaves the critical section. If the main thread then also
      > starts a GC while holding the lock, this will result in a deadlock.
      >
      > A GC can't start until the background thread reaches a safepoint and
      > the main thread can't leave the critical section before the GC ran.
      >
      > This CL introduces a new version of SharedMutexGuard named
      > RecursiveSharedMutexGuardIfNeeded. This class will park the thread
      > when blocking is needed and will unpark the thread again as soon as
      > the lock was acquired successfully. This resolves the deadlock on
      > safepointing.
      >
      > Turbofan can then simply use that class internally for
      > MapUpdaterGuardIfNeeded.
      >
      > Bug: v8:10315, chromium:1218318
      > Change-Id: Ice04b222cc979e4905791118caede26e71fca6de
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953288
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75107}
      
      Bug: v8:10315
      Bug: chromium:1218318
      Change-Id: Ic56afb14a537e0cbf412311f11407c1f09278225
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2958408Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75124}
      e9c4ff40
  5. 11 Jun, 2021 3 commits
    • Zhi An Ng's avatar
      Revert "[heap] Introduce ParkedSharedMutexGuardIf and use it in compiler" · 14fda804
      Zhi An Ng authored
      This reverts commit 4cd856ee.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/16843/overview
      
      Original change's description:
      > [heap] Introduce ParkedSharedMutexGuardIf and use it in compiler
      >
      > In some cases it could happen that the concurrent compiler tries to get
      > a shared lock on a mutex that is already exclusively held by the main
      > thread. The background thread will then block itself until the
      > main thread leaves the critical section. If the main thread then also
      > starts a GC while holding the lock, this will result in a deadlock.
      >
      > A GC can't start until the background thread reaches a safepoint and
      > the main thread can't leave the critical section before the GC ran.
      >
      > This CL introduces a new version of SharedMutexGuard named
      > RecursiveSharedMutexGuardIfNeeded. This class will park the thread
      > when blocking is needed and will unpark the thread again as soon as
      > the lock was acquired successfully. This resolves the deadlock on
      > safepointing.
      >
      > Turbofan can then simply use that class internally for
      > MapUpdaterGuardIfNeeded.
      >
      > Bug: v8:10315, chromium:1218318
      > Change-Id: Ice04b222cc979e4905791118caede26e71fca6de
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953288
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75107}
      
      Bug: v8:10315
      Bug: chromium:1218318
      Change-Id: Ied5d8d8f3e4c7e036a5a42a25c43e8ca1ecc1218
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2956698
      Auto-Submit: Zhi An Ng <zhin@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/master@{#75108}
      14fda804
    • Dominik Inführ's avatar
      [heap] Introduce ParkedSharedMutexGuardIf and use it in compiler · 4cd856ee
      Dominik Inführ authored
      In some cases it could happen that the concurrent compiler tries to get
      a shared lock on a mutex that is already exclusively held by the main
      thread. The background thread will then block itself until the
      main thread leaves the critical section. If the main thread then also
      starts a GC while holding the lock, this will result in a deadlock.
      
      A GC can't start until the background thread reaches a safepoint and
      the main thread can't leave the critical section before the GC ran.
      
      This CL introduces a new version of SharedMutexGuard named
      RecursiveSharedMutexGuardIfNeeded. This class will park the thread
      when blocking is needed and will unpark the thread again as soon as
      the lock was acquired successfully. This resolves the deadlock on
      safepointing.
      
      Turbofan can then simply use that class internally for
      MapUpdaterGuardIfNeeded.
      
      Bug: v8:10315, chromium:1218318
      Change-Id: Ice04b222cc979e4905791118caede26e71fca6de
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953288
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75107}
      4cd856ee
    • Dominik Inführ's avatar
      [heap] Optimize ParkedMutexGuard · 7b1d3f7a
      Dominik Inführ authored
      We do not need to park/unpark when we can acquire the lock without
      blocking.
      
      Bug: v8:10315, chromium:1218318
      Change-Id: I7909936531ffe83087182d50e759113a9305fbcf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953287
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75097}
      7b1d3f7a
  6. 26 Nov, 2020 1 commit
  7. 25 Nov, 2020 1 commit
  8. 19 Nov, 2020 1 commit
    • Dominik Inführ's avatar
      Reland "[heap] Introduce LocalIsolate for main thread" · dc45361e
      Dominik Inführ authored
      This is a reland of e95e1b62
      
      After landing https://crrev.com/c/2546682, this CL can be relanded
      without changes.
      
      Original change's description:
      > [heap] Introduce LocalIsolate for main thread
      >
      > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      > kept alive during the whole lifetime of the Isolate. The main thread
      > LocalIsolate starts in the Running state in contrast to the background
      > thread LocalIsolates (those start in Parked).
      >
      > Code paths in Turbofan that used to create a LocalIsolate on the main
      > thread can now simply use the main thread LocalIsolate.
      >
      > LocalIsolate for the main thread will help in reducing differences
      > between the main and background threads. The goal is that the main
      > thread behaves more like a background thread.
      >
      > The main thread LocalIsolate should also make it simpler to share code
      > between main thread and background threads by using LocalIsolate for
      > both.
      >
      > Bug: v8:10315
      > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71226}
      
      Bug: v8:10315
      Change-Id: I418b1217aeac4f3c44a0aa514dea9864f8a58656
      TBR: szuend@chromium.org, yangguo@chromium.org, ulan@chromium.org, leszeks@chromium.org, neis@chromium.org
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543399Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71274}
      dc45361e
  9. 17 Nov, 2020 2 commits
    • Michael Achenbach's avatar
      Revert "[heap] Introduce LocalIsolate for main thread" · 9235f258
      Michael Achenbach authored
      This reverts commit e95e1b62.
      
      Reason for revert:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/23064
      
      Original change's description:
      > [heap] Introduce LocalIsolate for main thread
      >
      > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      > kept alive during the whole lifetime of the Isolate. The main thread
      > LocalIsolate starts in the Running state in contrast to the background
      > thread LocalIsolates (those start in Parked).
      >
      > Code paths in Turbofan that used to create a LocalIsolate on the main
      > thread can now simply use the main thread LocalIsolate.
      >
      > LocalIsolate for the main thread will help in reducing differences
      > between the main and background threads. The goal is that the main
      > thread behaves more like a background thread.
      >
      > The main thread LocalIsolate should also make it simpler to share code
      > between main thread and background threads by using LocalIsolate for
      > both.
      >
      > Bug: v8:10315
      > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#71226}
      
      TBR=ulan@chromium.org,yangguo@chromium.org,neis@chromium.org,leszeks@chromium.org,szuend@chromium.org,dinfuehr@chromium.org
      
      Change-Id: Ia70b4bfe3b8fa26bf8d6a7dc612a310b0ed54073
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543937Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71228}
      9235f258
    • Dominik Inführ's avatar
      [heap] Introduce LocalIsolate for main thread · e95e1b62
      Dominik Inführ authored
      Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is
      kept alive during the whole lifetime of the Isolate. The main thread
      LocalIsolate starts in the Running state in contrast to the background
      thread LocalIsolates (those start in Parked).
      
      Code paths in Turbofan that used to create a LocalIsolate on the main
      thread can now simply use the main thread LocalIsolate.
      
      LocalIsolate for the main thread will help in reducing differences
      between the main and background threads. The goal is that the main
      thread behaves more like a background thread.
      
      The main thread LocalIsolate should also make it simpler to share code
      between main thread and background threads by using LocalIsolate for
      both.
      
      Bug: v8:10315
      Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71226}
      e95e1b62