This is a reland of 86038ecfdc
Compared to the previous CL this one is adding a TSAN suppression
for GlobalSafepoint::EnterSafepointScope. local_heaps_mutex_ of client
isolates may be locked in any order. This would be detected by TSAN as a
potential race. Add some additional DCHECKs to compensate for that
missing test coverage.
As a cleanup this CL also removes the unused methods ContainsLocalHeap()
and ContainsAnyLocalHeap() from LocalHeap.
Original change's description:
> [heap] Optimize time to reach global safepoint
>
> Initial support for global safepoints kept it simple by entering a
> safepoint for each of them one after another. This means
> time-to-global-safepoint is the sum of all time-to-safepoint operations.
> We can improve this slightly by splitting up the safepoint iteration
> into two operations:
>
> 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
> and sets SafepointRequested flag for all client threads)
> 2) Block until all runnning client threads reach a safepoint
>
> We now perform operation 1) for all clients first and only then start
> with operation 2).
>
> Bug: v8:11708
> Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78308}
Bug: v8:11708, v8:12492
Change-Id: I7087ba23c08f2d4edb9b632eef3c218fc76342e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328786
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78583}
This reverts commit e26cd87496.
Reason for revert: The issue has been fixed. See related bug for description and CLs.
Original change's description:
> [heap] Add TSAN suppression for lock-order inversion in Scavenger
>
> The Scavenger currently requires taking the lock for OLD->NEW processing
> and can also take another lock for sweeping a different page.
>
> Since order of pages during scavenge and sweep is unstable this may
> result in lock order inversion reports on TSAN when long-running
> programms are only executed on a single thread.
>
> The report is a false positve, hence flag it as suppression until we
> redesign this particular piece.
>
> No-try: true
> Bug: v8:6923
> Change-Id: I82355be1c8d83ea61cc21152aeb10b58b1dc4b86
> Reviewed-on: https://chromium-review.googlesource.com/716261
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48504}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6923
Change-Id: I7711466c6e2175dcab8d64d6a642e458e1cde3f5
Reviewed-on: https://chromium-review.googlesource.com/738110
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48913}
The Scavenger currently requires taking the lock for OLD->NEW processing
and can also take another lock for sweeping a different page.
Since order of pages during scavenge and sweep is unstable this may
result in lock order inversion reports on TSAN when long-running
programms are only executed on a single thread.
The report is a false positve, hence flag it as suppression until we
redesign this particular piece.
No-try: true
Bug: v8:6923
Change-Id: I82355be1c8d83ea61cc21152aeb10b58b1dc4b86
Reviewed-on: https://chromium-review.googlesource.com/716261
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48504}
