-
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: Georg Neis <neis@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75107}
4cd856ee