Running dart code on mutator thread outside of isolate still should follow limits on number of concurrent mutators in the vm.
Also this fixes inconsistency when entering isolate group as mutator, where original worker was marked as blocked while thread was actually running dart code. That inconsitency showed up as sporadic crash on isolate_group_shared_init_test with increased number of spawned isolates.
TEST=isolate_group_shared_init_test
BUG=https://github.com/dart-lang/sdk/issues/60877
Change-Id: I8917be903bb5517940dad3e5dab143d5ed5fdf79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/432900
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Add a mutex to guard execution of vm:shared field initialization.
TEST=isolate_group_shared_init_test
BUG=dartbug.com/60699
Change-Id: If544351fc26bfcc7fb9703954efe785989d488bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431742
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Having forwarding tables on the Thread allows for those tables to be used in dart mutator thread running in IsolateGroup-shared context. On 32-bit platforms(arm) the forwarding tables are used during [SendPort.send] message verification.
Fixes https://github.com/dart-lang/sdk/issues/60817
TEST=isolate_group_shared_send_test
Change-Id: I58b33c14026584330b594776e812fe1d48bc2fd5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431942
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This should help speeding up new isolate creation (or running dart code on mutator thread when it is supported).
TEST=ci
Change-Id: I88b5deeb33e72694cb3e2727cf5668ce15fd8c6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420361
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Dart_Cleanup waited only for the isolate group to be unregistered, which happens before the group's heap is deleted.
TEST=tsan
Change-Id: I20046516635adbcbf63eae460d7b09e7e26169d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416283
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
dart2js benchmarks use --print-metrics to track heap usage, with the
shift to running dart2js using aproduct mode AOT snapshot these
metrics are not printed resulting in errors from the benchmarks.
The size increase from turning on these isolate group metrics in product
mode is not very significant (about 2k).
TEST=ci
Change-Id: Ie9bbaecd57a2b45c27a158f6eb4988966a41ce67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405220
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Once we enter the isolate, other threads may read the main port as part of attempting to bring all the group members to a reload safepoint.
TEST=tsan
Change-Id: Ie7ccfd8672c9b923c7e071023a418ddbc58660ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398780
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Running mutator
holds safepoint operation scope starting old space GC
waiting for old space tasks to reach 0
Concurrent marker
holds old space tasks > 0
waiting for isolates_list_ lock to interrupt for finalization
Exiting mutator
holds isolates_list_ lock_ to unregister isolate
waiting for safepoint to end TransitionVMToBlocked
Reorder isolate [un]registeration to not need safepoint transition to acquire the isolates_list_ lock.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/59574
Change-Id: Ia98fabd654c880b253893a0598d2e26ed77f52da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/397660
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
I haven't been able to get a solid repro the tsan flake locally, and I'm not sure how to write a test for it, but this change is pretty uncontroversial anyway, so I'm inclined to just land it and see what happens.
I have some weak evidence that this fixes the issue though. Before this change I ran the flaky command about 500 times before I saw a failure (though I didn't get any useful data from the failure, and it didn't look quite the same as the bug). With the change, the command ran 3500 times before flaking. I'm not sure if it's the same flake though (rr isn't working for me atm).
Bug: https://github.com/dart-lang/sdk/issues/56900
Fixes: https://github.com/dart-lang/sdk/issues/56900
Change-Id: I939e8ceca4051ec91e942ca38a2b01477b67ddd8
TEST=CI
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392162
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
This reland commit 5a32d8bc7c with a fix
for thread leak (Issue #56717): when `ThreadPool` is shutting down
asynchronously the last worker should detach itself to prevent
leaking associated low-level data structures, because no thread will
join it.
A hang in service isolate shutdown (caused by an existing bug) was fixed by commit 157a0dc7f9.
This CL turns native ports into a thin abstraction over underlying
thread pool instead of building them as full fledged MessageHandler.
This allows to easily implement a variation of native ports which can
handle messages concurrently with the given degree of concurrency.
This type of port can be used to greatly simplify implementation of
IOService - which previously had to do its own concurrency management
on top of "single threaded" native ports. This capability is exposed
as `Dart_NewConcurrentNativePort` API.
The new implementation is in general much cleaner then the old one
with one exception: `Dart_CloseNativePort` API has unfortunate design
where underlying message handler is destroyed asynchronously and
`Dart_CloseNativePort` returns immediately without waiting for pending
tasks to complete. Implementing this on top of `ThreadPool` requires
some changes to thread pool implementation.
Issue https://github.com/dart-lang/sdk/issues/55844
Closes https://github.com/dart-lang/sdk/issues/56717
TEST=ci
Change-Id: Ic68bfb60757685afd75c80a70cdec66cc13c149b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385000
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This reverts commit 5a32d8bc7c.
Reason for revert: DartIsolateTest.CanCreateServiceIsolate flutter engine unit test hangs on Windows.
Original change's description:
> [vm] Simplify implementation of native ports
>
> This CL turns native ports into a thin abstraction over underlying
> thread pool instead of building them as full fledged MessageHandler.
>
> This allows to easily implement a variation of native ports which can
> handle messages concurrently with the given degree of concurrency.
> This type of port can be used to greatly simplify implementation of
> IOService - which previously had to do its own concurrency management
> on top of "single threaded" native ports. This capability is exposed
> as `Dart_NewConcurrentNativePort` API.
>
> The new implementation is in general much cleaner then the old one
> with one exception: `Dart_CloseNativePort` API has unfortunate design
> where underlying message handler is destroyed asynchronously and
> `Dart_CloseNativePort` returns immediately without waiting for pending
> tasks to complete. Implementing this on top of `ThreadPool` requires
> some changes to thread pool implementation.
>
> Issue https://github.com/dart-lang/sdk/issues/55844
>
> TEST=ci
>
> Change-Id: I062040ff233e93962ae93684e9b044d8facdaffc
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382163
> Commit-Queue: Slava Egorov <vegorov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
Change-Id: I7de27793a54072e974bf1a9f17a07c12159a202d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384481
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This CL turns native ports into a thin abstraction over underlying
thread pool instead of building them as full fledged MessageHandler.
This allows to easily implement a variation of native ports which can
handle messages concurrently with the given degree of concurrency.
This type of port can be used to greatly simplify implementation of
IOService - which previously had to do its own concurrency management
on top of "single threaded" native ports. This capability is exposed
as `Dart_NewConcurrentNativePort` API.
The new implementation is in general much cleaner then the old one
with one exception: `Dart_CloseNativePort` API has unfortunate design
where underlying message handler is destroyed asynchronously and
`Dart_CloseNativePort` returns immediately without waiting for pending
tasks to complete. Implementing this on top of `ThreadPool` requires
some changes to thread pool implementation.
Issue https://github.com/dart-lang/sdk/issues/55844
TEST=ci
Change-Id: I062040ff233e93962ae93684e9b044d8facdaffc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382163
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
AllocateSuspendState was calling `Instance::SetField` but did not allow lazy deopt to occur. Possibility of lazy deopt from those
field stores is only theoretical, but it manifested as a
deadlock between background compiler and main thread: if main
thread calls `SetField` which tries to acquire write access to
the program lock, while background compiler has already
acquired write access to the program lock and is trying to
stop all mutators at a GC+Deopt safepoint then we will
deadlock as `AllocateSuspendState` does not allow Deopts
(safepoint level was lowered by 5bc107c29d).
We fix this problem by bypassing field guard and simply
writing affected fields directly in AllocateSuspendState.
We make sure to initialize guarded state for these fields
eagerly, so it never needs to change.
TEST=added assertion which validates that attempting to acquire program lock for write can only occur where GC+Deopt are permitted.
Change-Id: I6ee6b82f3296f49f799c0069e42850711c9320ac
Bug: b/355226004
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381240
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This CL also removes ability to assign names to mutexes which was
added in c25ebfff96 but did not yield
any interesting data.
TEST=ci
CoreLibraryReviewExempt: Changes to dart:concurrent only.
Cq-Include-Trybots: luci.dart.try:vm-fuchsia-release-x64-try,vm-win-debug-x64-try,vm-win-release-x64-try,vm-aot-linux-product-x64-try
Change-Id: Id41e1d29832f6008e02f0a571ee67564e1a84224
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375300
Reviewed-by: Martin Kustermann <kustermann@google.com>
Decorating a field with 'vm:shared' pragma makes values in this field accessible to all isolates in an isolate group.
Introduce `channel` to the `Version` class so that the pragma can only be enabled on main and dev channels.
TEST=shared_test, shared_fail_without_flag_test
BUG=https://github.com/dart-lang/sdk/issues/55991
Change-Id: I843c9f0d2ffc9f2ced7ddc4006bb6f9ca4e2ddf4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370064
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
The fallback mechanism wasn't working because the embedded struct by
value wasn't nullptr initialized.
TEST=tested by commenting out `Dart_InitializeNativeAssetsResolver`
in `main_impl.cc`. Without this CL it segfaults, with this CL it works
as expected.
Closes: https://github.com/dart-lang/sdk/issues/56006
Change-Id: If93cf9b077a2791a8385bdc8e75708dd95c8ead6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371620
Reviewed-by: Martin Kustermann <kustermann@google.com>
Ryan Macnak