commit | 2ea92acba5b12484a348c915a39a8cb562131f94 | [log] [tgz] |
---|---|---|
author | Martin Kustermann <kustermann@google.com> | Fri Apr 21 13:56:49 2023 +0000 |
committer | Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Apr 21 13:56:49 2023 +0000 |
tree | bc9377225612bc68c97fef8b8ae20dbc03b9f1ed | |
parent | 742612ddaca82b51387a129ed50738256ae2e243 [diff] |
[vm] Make reloading of isolate groups use new safepoint-level mechanism The current hot-reload implementation [0] will perform a reload by first sending OOB messages to all isolates and waiting until those OOB messages are being handled. The handler of the OOB message will block the thread (and unschedule isolate) and notify the thread performing reload it's ready. This requires that all isolates within a group can actually run & block. This is the case for the VM implementation of isolates (as they are run an unlimited size thread pool). Though flutter seems to multiplex several engine isolates on the same OS thread. Reloading can then result in one engine isolate performing reload waiting for another to act on the OOB message (which it will not do as it's multiplexed on the same thread as the former). Now that we have a more flexible safepointing mechanism (introduced in [1]) we can utilize for hot reloading by introducing a new "reloading" safepoint level. Reload safepoints ----------------------- We introduce a new safepoint level (SafepointLevel::kGCAndDeoptAndReload). Being at a "reload safepoint" implies being at a "deopt safepoint" which implies being at a "gc safepoint". Code has to explicitly opt-into making safepoint checks participate / check into "reload safepoints" using [ReloadParticipationScope]. We do that at certain well-defined places where reload is possible (e.g. event loop boundaries, descheduling of isolates, OOM message processing, ...). While running under [NoReloadScope] we disable checking into "reload safepoints". Initiator of hot-reload ----------------------- When a mutator initiates a reload operation (e.g. as part of a `ReloadSources` `vm-service` API call) it will use a [ReloadSafepointOperationScope] to get all other mutators to a safepoint. For mutators that aren't already at a "reload safepoint", we'll notify them via an OOB message (instead of scheduling kVMInterrupt). While waiting for all mutators to check into a "reload safepoint", the thread is itself at a safepoint (as other mutators may perform lower level safepoint operations - e.g. GC, Deopt, ...) Once all mutators are at a "reload safepoint" the thread will take ownership of all safepoint levels. Other mutators ----------------------- Mutators can be at a "reload safepoint" already (e.g. isolate is not scheduled). If they try to exit safepoint they will block until the reload operation is finished. Mutators that are not at a "reload safepoint" (e.g. executing Dart or VM code) will be sent an OOB message indicating it should check into a "reload safepoint". We assume mutators make progress until they can process OOB message. Mutators may run under a [NoReloadScope] when handling the OOM message. In that case they will not check into the "reload safepoint" and simply ignore the message. To ensure the thread will eventually check-in, we'll make the destructor of [~NoReloadScope] check & send itself a new OOB message indicating reload should happen. Eventually getting the mutator to process the OOM message (which is a well-defined place where we can check into the reload safepoint). Non-isolate mutators such as the background compiler do not react to OOB messages. This means that either those mutators have to be stopped (e.g. bg compiler) before initiating a reload safepoint operation, the threads have to explicitly opt-into participating in reload safepoints or the threads have to deschedule themselves eventually. Misc ---- Owning a reload safepoint operation implies also owning the deopt & gc safepoint operation. Yet some code would like to ensure it actually runs under a [DeoptSafepointOperatoinScope]/[GCSafepointOperationScope]. => The `Thread::OwnsGCSafepoint()` handles that. While performing hot-reload we may exercise common code (e.g. kernel loader, ...) that acquires safepoint locks. Normally it's disallows to acquire safepoint locks while holding a safepoint operation (since mutators may be stopped at places where they hold locks, creating deadlock scenarios). => We explicitly opt code into participating in reload safepointing requests. Those well-defined places aren't holding safepoint locks. => The `Thread::CanAcquireSafepointLocks()` will return `true` despite owning a reload operation. (But if one also holds deopt/gc safepoint operation it will return false) Example where this matters: As part of hot-reload, we load kernel which may create new symbols. The symbol creation code may acquire the symbol lock and `InsertNewOrGet()` a symbol. This is safe as other mutators don't hold the symbol lock at reload safepoints. The same cannot be said for Deopt/GC safepoint operations - as they can interrupt code at many more places where there's no guarantee that no locks are held. [0] https://dart-review.googlesource.com/c/sdk/+/187461 [1] https://dart-review.googlesource.com/c/sdk/+/196927 Issue https://github.com/flutter/flutter/issues/124546 TEST=Newly added Reload_* tests. Change-Id: I6842d7d2b284d043cc047fd702b7c5c7dd1fa3c5 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296183 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Slava Egorov <vegorov@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.