| commit | 04195fcf14467d2c2a5d94387dacc42844247bc0 | [log] [tgz] |
|---|---|---|
| author | Martin Kustermann <kustermann@google.com> | Mon May 22 12:41:38 2023 +0000 |
| committer | Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon May 22 12:41:38 2023 +0000 |
| tree | 5a8e8401321b408e88556cf3445c40b184889bee | |
| parent | 42040116e0d4b8f4e744158aa3af68d491244b89 [diff] |
[vm] A thread owning a safepoint operation should keep its mutator slot 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>
Dart is:
Optimized for UI: Develop with a programming language specialized around the needs of user interface creation.
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app.
Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.