GitLab

This change add a mutex locker which enters a safepoint while trying to acquire the mutex lock. This means that threads waiting to acquire a lock would be parked allowing a GC.
In addition to entering a safepoint the locker will also ensure that if we block while leaving the safepoint, due to another thread having scheduled a GC, the lock will be released and the safepoint reentered. This allows for the lock to be acquired during sweeping, specifically in weak processing and finalization which could otherwise deadlock and cause the other scheduled GC to time out.

This change does however not fix the issue where the lock has been acquired and another safepoint is entered while having the lock. This could still cause a timeout. There is an instance of this scenario in the webdatabase's DatabaseBackendBase.cpp::performOpenAndVerify where we get the guidMutex and while commiting the transaction enter a safepoint in the SQLiteStatement::prepare and SQLiteStatement::step calls.
To fix the above we have to restructure the webdatabase code to not hold the global guidMutex lock while doing sync operations.

This change does make it less likely that we hit the empty assert in the terminate-during-sync-websql.html test, but due to the above issue it can still happen. We should consider still doing the restructuring in https://codereview.chromium.org/335823002/ to completely get rid of the flakiness.


R=ager@chromium.org, erik.corry@gmail.com, haraken@chromium.org, oilpan-reviews@chromium.org, tkent@chromium.org, vegorov@chromium.org, zerny@chromium.org
BUG=375671

Review URL: https://codereview.chromium.org/332393002

git-svn-id: svn://svn.chromium.org/blink/trunk@176347 bbb929c8-8fbe-4397-9dbb-9b2b20218538