Attempts to acquire safepoint lock while in SafepointOperationScope could result
in deadlocks if somebody else was holding that lock when they were forced to a safepoint.
Clean up few places where locks were acquired in SafepointOperationScope.
Introduce StoppedMutatorsScope and GroupDebugger::RunUnderReadLockIfNeeded that acquires
a lock only if it runs outside of StoppedMutatorsScope - to prevent such deadlocks.
Also fix tsan warning about data race around message_notify_callback by making it atomic.
TEST=tsan runs of debugger CI tests
Fixes https://github.com/dart-lang/sdk/issues/45527
Fixes https://github.com/dart-lang/sdk/issues/45549
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: Ibb53d9ce760d869e044e17075aeebf20fc0016a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193582
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
To avoid a O(n) traversal of isolates in order to find pending deopts,
we'll move the pending deopt state to the Thread. It's really a property
of a thread: when the thread's stack gets unwound - via return or
exceptional flow - we remove pending deopts.
This CL also encapsulates the pending deopt logic into a [PendingDeopts]
class - thereby avoiding logic around manipulating this array being
spread around. It simplifies the already very big [Isolate] class.
TEST=Refactoring of existing code.
Issue https://github.com/dart-lang/sdk/issues/36097
Closes https://github.com/dart-lang/sdk/issues/45168
Change-Id: I5a9b18c577f21a0f2a88332b1bc26641ec39d2af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188521
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Many years ago those bailouts were seemingly added due to deferred
loading in [0]. Though it seems like those bailouts might've become
obsolete.
All places that clear the IC array on the function should run inside
a [NoBackgroundCompiler] scope, therefore ensuring no optimizing
compilations are done at that time. Those places also clear code,
therefore forcing re-compilation of unoptimized code (which will
re-create the ICData).
[0] https://codereview.chromium.org/1672873003/#ps60001
TEST=Removing dead code.
Change-Id: Iec4f22be500f6e874fa5286b51396bd6d978dd6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187902
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The background compiler can cause finalization of classes which can
cause deoptimization of code.
Any deoptimization will iterate over all mutator threads and marks
frames on the stack to be deoptimized. This requires saving old
(fp, pc) state. This state is currently saved on the current isolate's
pending deopt array (via `Thread::Current()->isolate()->AddPendingDeopt()`)
instead of the isolate whose stack got walked.
As part of making the compiler independent of `Isolate::Current()` we
pass the isolate explicitly.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing code.
Change-Id: I9327f3b76981fc16c1879a873edf37df1cbdd8bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182380
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Currently we have things called XPtr which are not what you get from ptr().
Old world:
handle->raw() returns RawObject* (tagged)
raw_obj->ptr() returns RawObject* (untagged)
After 6fe15f6df9:
handle->raw() returns ObjectPtr
obj_ptr->ptr() returns ObjectLayout*
New world:
handle->ptr() returns ObjectPtr
obj_ptr->untag() returns UntaggedObject*
TEST=ci
Change-Id: I6c7f34014cf20737607caaf84979838300d12df2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149367
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Alexander Aprelev