Ryan Macnak
d36adbacaf
The former contents of the VM isolate are now included into each isolate group. This makes each isolate group's heap independent, and in particular allows each heap to be allocated to a separate pointer cage (not done in this CL). The duplicated stubs that allowed PC relative calls are removed, since the originals can now be the target of PC relative calls. The bootstrapping needing to load an AppJIT or AppAOT snapshot is reduced to allocating the oddballs. The code is entirely dropped in the AOT runtime, but the JIT runtime still has it to allow for flags to affect the compilation of the stub code. Further refactoring might be able to remove this for the JIT runtime too, with only gen_snapshot knowing how to bootstrap. Class serialization no longer distinguishes predefined classes. The page containing null is marked as never-evacuate. null, false and true must not move because the compiler relies on their low bits having certain patterns for some optimizations. (Previously, the entire VM isolate heap never moved.) Compaction is disabled for IA32. Due to register pressure, some stub calls must not use a scratch register and embed the address of Code. The page containing the call-through-safepoint stub is frozen when running with --write-protect-code and the stub is created at runtime (instead of loaded from an AppJIT or AppAOT snapshot). This stub must remain executable even during a safepoint, as a foreign call might during return during a safepoint and only block after the stub directs it to the runtime. The snapshot symbols are renamed to kDartSnapshotData and kDartSnapshotText. There is no need to distinguish the VM isolate's snapshot, and snaphots are per isolate group not per isolate. Aliases with the old names are added to ease migration. Some global flags that were automatically set based on the VM isolate's snapshot are now isolate group flags and automatically set by the isolate group's snapshot. TEST=ci Change-Id: Iee82016057d609112e9b021d178fc3d4d18b5044 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/500621 Reviewed-by: Alexander Markov <alexmarkov@google.com> Reviewed-by: Tess Strickland <sstrickl@google.com> SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com> Commit-Queue: Ryan Macnak <rmacnak@google.com>
Dart Engine
The include/dart_engine.h provides additional functions to embed the Dart VM
and to call Dart functions from kernel and AOT snapshots. It is not intended to
be a full-featured API, and should be used together with dart_api.h.
It is intended for reusing of existing Dart code in non-Dart programs, and allows to use Dart snapshots as shared libraries: the caller can start one or several isolates from Dart snapshots and call Dart functions from it.
Comparing to dart_api.h it brings the following:
- Full initialization of Dart VM, including initializing core libraries.
- Easier handling of isolate messages
- Lock-guarded functions to enter/exit isolates.
See examples in samples/embedder for usages of the API.
Handling isolate messages
In dart_api.h there are two possible ways to handle asynchronous
isolate messages:
Dart_MessageNotifyCallback: Users can pass a callback to get notifications about messages to handle, but handling messages still requires entering an isolate, entering a scope, callingDart_HandleMessage, and then leaving a scope and an isolate.Dart_RunLoop: Users can invoke it on a separate thread, but then they won't be able to enter isolates from other threads.
As an alternative, dart_engine.h provides a simpler function
DartEngine_HandleMessage, which encapsulates isolate and scope management, and
it allows to specify per isolate / default message schedulers, which only need
to schedule an execution DartEngine_HandleMessage with the right isolate.
Users can create their own DartEngine_MessageScheduler struct and pass it to
DartEngine_SetMessageScheduler / DartEngine_SetDefaultMessageScheduler. See
samples/embedder/run_timer_async.cc and samples/embedder/run_timer.cc
examples.
Entering / leaving isolates
Because engine API uses its own message handling, it is important to use
DartEngine_AcquireIsolate / DartEngine_ReleaseIsolate instead of
Dart_EnterIsolate / Dart_ExitIsolate. DartEngine_AcquireIsolate blocks
until an isolate can be entered by trying to obtain an internal lock (which is
released by DartEngine_ReleaseIsolate), while Dart_EnterIsolate crashes if
some other thread has entered the same isolate.