Threads that own safepoint operations (e.g. a thread owning
[ReloadSafepointOperation]) are free to exit & re-enter. Owning a
safepoint operation only means that other threads are at well defined
places.
We limit the number of active mutators that can be running at the same
time - mainly due to the way our GC works today. This is maintained by
threads blocking on entering when there's too many mutators already.
If a thread owns a safepoint operation and exits, it should not give up
it's mutator slot to ensure it will be able to re-enter.
A concrete case when this can happen: We have many isolates and we run
in `--hot-reload-test-mode`. One isolate will own a reload safepoint
operation & perform reload. As part of reload it will exit the isolate
and send a request to the `kernel-service` and wait for it's reply. Once
it gets a replay it will re-enter the isolate. Now this re-entering
could be blocking if another thread took the mutator slot (which can
happen, as we get mutator slot before we try to check-in to safepoint
when entering).
In the future we may unify the safepoint mechanism with the mutator
count mechanism.
Closes https://github.com/dart-lang/sdk/issues/52441
TEST=Fixes flaky timeouts of ffi/invoke_callback_after_suspension_test
Change-Id: Icc5dbf59b4270653c9e6e316531f5b3e086db2fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/304682
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Martin Kustermann
04195fcf14