CodeBreakpoint class tracks patching of the call targets for the purpose of routing the call to the debugger runtime.
With this CL CodeBreakpoint instance is managed by GroupDebugger, debugger class owned by IsolateGroup, and can be associated with multiple BreakpointLocation, one location per isolate that set a breakpoint at particular code location.
TEST=observatory/tests/service/break_on_function_child_isolate_test
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I3b3d0974a0fb9668742e5c1e2a2ce13b84b1d630
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190732
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@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>
This is the initial implementation of hot reload with multi-isolate
groups.
Implementation:
As before, when a service API call triggers a reload it will be routed
as an OOB message to a specific isolate (**). As opposed to before, that
isolate has now to coordinate with all other isolates, ensuring that it
"owns" the reload and all other isolates are waiting in a state that
allows reload.
This is implemented as a [ReloadOperationScope] which first participates
in other reloads (if there are any) and then owns the reload. It will
send a new kind of service message to all other registered isolates. All
of them have to check in before reload can proceed. If a new isolate
is about to join the group, it will participate when registering the
isolate. If an old isolate wants to die, it will participate when
unregistering the isolate.
This means that in addition to the existing StackOverFlow checks that
can process OOB messages and therefore reload, we'll have isolate
registration and unregistration as well as a new
Isolate::kCheckForReload OOB message handler where an isolate can
participate in a reload.
We consider the isolate group to be reloadable if the main isolate has
loaded the program and set the root library. Helper isolates don't need
to load any more kernel code and only initialize core libraries, so it's
fine to reload them during this time.
(**) The reason we continue to send reload service API calls to any
isolate in an isolate group is that re-loading might involve calling out
to the embedder's tag handler. Doing so currently requires an active
isolate.
If we allowed a subset of dart_api.h (the subset needed by the tag
handler) to be used only with an active IsolateGroup instead of an
active Isolate we could remove this requirement.
Edge cases:
There's various edge cases to consider: The main edge case is, we currently
maintain an upper limit to the number of isolates executing in parallel
(to ensure each can have big enough chunk of new space, i.e. TLAB).
If there are more isolates with active work they are waiting until one
of the exiting ones "yields". To ensure progress, if any such actively
running isolate gets a request to participate in a reload, it will mark
its own thread as "blocked" and therefore "yields", so another isolate
can make progress until all isolates are participating and the reload
can start.
Marking an isolate as "blocked" happens by exiting that isolate. It will
free up it's TLAB, decrease active mutator count and (if running on VM's
thread pool) also temporarily increase the thread pool size.
The side-effect of this is that it will use one pthread per isolate
during reload. In the future we can extend this first implementation, by
specially handling isolates that don't have a message handler running.
Doing so would require careful consideration to avoid races.
Testing:
In order to test this we use a small helper framework for reload tests.
The helper framework will, similar to real world reload e.g. in flutter,
will spawn a subprocess. It will use the service API to trigger reloads
in this subproces.
To synchronize between the reload driver and the application being
reloaded it allows watching for events to be printed to stdout/stderr.
The reload test itself can be written - similar to multitests - with
annotations such as `// @include-in-relload-0` in them. The testing
framework will then generate multiple application versions that all get
compiled to kernel.
For simplicity we generate the kernel using the standalone VM with
`--snapshot-kind=kernel` and avoid using the incremental compiler.
There are 4 different tests exercising different aspects of
multi-isolate reload:
vm/dart_2/isolates/reload_active_stack_test:
Performs a reload while a fixed number of isolates have an active
stack, thereby ensuring e.g. that all frames of all isolate mutator
stacks get deoptimized, ...
vm/dart_2/isolates/reload_no_active_stack_test:
Similar to the test above, but instead of having an active stack the
isolates can yield to the event loop, possibly be even descheduled
vm/dart_2/isolates/reload_many_isolates_test:
Similar to the test above, but this test uses many more isolates.
vm/dart_2/isolates/reload_many_isolates_live_and_die_test:
Performs a reload where isolates get spawned and die all the time.
There are always P isolates alive at any given point in time, each
of them spawns children when their parent has died.
Performing a reload catches isolates as various stages of their
lifecycle and can therefore cover a lot of corner cases.
TEST=vm/dart_2/isolates/reload_*_test.dart
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I97039b4084de040b7f2e22f5832a40d57ba398d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187461
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Whether a given isolate allows reloading is really a property of the
thread not the isolate (where it was before) or isolate group (where
it was moved to), so this CL moves it to Thread.
As the thread's stack is going down and up, NoReloadScope's might be
entered or exited, just as with our many other scopes, such as
NoOOBMessageScope/...
Longer term we might need to find a better mechanism to deal with
different OOB messages. For example: Reload as well as OOB messages
are disabled during static field initialization. Though that means *all*
OOB messages cannot reach the isolate during initialization of a static
field (which can do arbitrary amount of work).
This is part of making hot-reload work with isolate groups.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing code.
Change-Id: I9e80c6d4a184c54c0373fef13af3264cc3f27ece
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187002
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
It's mainly hoisting an expression out of
IsolateGroup::{Increase,Decrease}MutatorCount to callers of it.
Right now we consider a Thread::{Exit,Enter} to be nested if there are
existing Dart frames on the stack. A future CL will have a case where
there's a nested exit&re-enter without Dart frames on the stack.
Trying to do this automatically by checking whether there's an
active api scope / zone on the thread fails due to some
asymmetry in our codebase.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing code.
Change-Id: Id70eda03efb2099487c5f0c8affd25ddff926553
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186287
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
As part of implementing hot-reload for isolate groups, we have to ensure
reloads on a group are performed using the same state of incremental
compiler.
This means we cannot use a specific isolate's information (such as it's
main port) for reloading purposes. Instead we use the unqiue isolate
group id when communicating with the kernel service.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Existing test coverage, future test when hot-reload is fully
implemented with isolate groups.
Change-Id: Ifab39cd2ba689c08507dfab4091cd26951ed54e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185320
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Since loading kernel will affect all isolates within a group, there
should be nothing isolate-specific inside the kernel loader. To ensure
we don't have (or introduce) any accidental uses, we add a
NoActiveIsolateScope to the main parts of kernel loading.
Only loading of native extensions - done by the kernel loader -
currently requires an active isolate. The reason for this is that
loading native extensions happen by calling out to embedder, which calls
back into the VM using the our embedding API (which currently requires
an active isolate)
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing implementation.
Change-Id: I96e64dbfe7148b76b8fa006fe5dbde8c1f904504
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184269
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
The object store related fields in [Isolate] are not needed anymore:
Isolate::object_store_
Isolate::cached_object_store_
Isolate::object_store_shared_ptr_
and can be directly accessed from [IsolateGroup].
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing implementation.
Change-Id: Ia01da92cbb4e7cf5862c8419e27578ea07d4bdf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184268
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
With --enable-isolate-groups we will start sharing JITed code. The JITed
code - which will be executed by all isolates - should therefore not
depend on a particular isolate's state, flags or any other
isolate-specific information.
To avoid accidental bugs where the compiler starts using
isolate-specific information, we ensure the compiler runs without a
current isolate.
This CL doesn't add NoActiveIsolateScope because on unoptimized compiles
of natives, the compiler calls out to embedder for eager native
resolution of native functions. This API forces embedder to callback
into VM atm.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Adds more checking.
Change-Id: I6c86674c010b74c15855652415706dbaa8749d33
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183692
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This CL moves the [ProgramReloadContext] from [Isolate] to
[IsolateGroup] - since the program is shared across isolates. Amongst
other things, it also deoptimizes stacks of all isolate mutators.
There is still future work to do for hot-reloading multiple isolates
within a group, this is only the first change.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing implementation.
Change-Id: Ic394de265e3922f84657de2da25a46179b624647
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183693
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This is to ensure that deferred library status is per isolate, rather than per isolate-group.
TEST=deferred_isolate_test.dart
Issue dartbug.com/36097
Change-Id: I1fb8b8f1830aac688a078fe0a82b06c7daa856fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184040
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
The logic for background compiler can be simplified due to:
* we only have one bg compiler
* it always optimizes
* it is allocated at isolate startup and freed on isolate shutdown
* an existing check in the compiler for whether the BG compiler is
disabled is racy and therefore not helpful
* when a mutator communicates with BG compiler it will use
SafepointMutexLocker instead of MutexLocker
This CL also ecapsulates disabling the BG compiler via a
NoBackgroundCompilerScope object. It allows nested disabling and guards
against races.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing code.
Change-Id: I36ed6592c9a8b91e94181698b7de662b4ee984e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183400
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
As part of making the compiler as well as hot-reload independent of
a particular isolate we move this boolean to `IsolateGroup`.
For hot-reloading isolate groups there are more changes needed that
come in the future. This CL is preparation for making the compiler
independent of current isolate.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing code.
Change-Id: I434cf1180bc963462e2901dfa83e915df9dc1712
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182561
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
As part of making the compiler independent of a particular isolate
(since all isolates in a group share the same JITed code) we move the
boxed field list to IsolateGroup.
Any isolate that hits the lazy compile stub will then drain the fields
to be deoptimized and performs that work.
A follow-up investigation can decide whether it's beneficial (or
hurtful) for single vs multi isolate scenarios to deoptimize the field
immediately in BG compiler (and interrupt mutator). It is possibly
disadvantagues for single isolate scenarios to do so, since it causes
more mutator interruptions.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing code.
Change-Id: I64b42ad99056b43a7264bcc30280b9ba39389a2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182505
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
As part of making the compiler and other subsystems independent
of `Isolate` we have to move various state from `Isolate` to
`IsolateGroup` (or to another place).
Part of that is `Isolate::reload_context()`. In order to avoid name
conflict of what a `reload_context()` is, we separate it into
`reload_context()` and `program_reload_context()` where the former
contains GC information and the latter contains information about
changes in program structure.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Pure refactoring - relying on existing test coverage.
Change-Id: I7e1b732ce8b34c8842718699d618be542bd59ff6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177863
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>
As part of making the compiler and other subsystems independent
of `Isolate` we have to move various state from `Isolate` to
`IsolateGroup` (or to another place).
The access of `ObjectStore::closure_functions()` was spread out over our
codebase, including from `Isolate`. This CL moves it to a centralized
place - ClosureFunctionsCache.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Pure refactoring - relying on existing test coverage.
Change-Id: I3b282623f07614cdc2c2a863bd5b9d6c7748d36f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177130
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
As part of making the compiler and other subsystems independent
of `Isolate` we have to move various state from `Isolate` to
`IsolateGroup`.
The class_table and object_store were already moved to `IsolateGroup`.
This CL only replaces usages of `Isolate::{object_store,class_table}`
with the equivalent in `IsolateGroup`.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Pure refactoring - relying on existing test coverage.
Change-Id: I34a0682d715b054d6c5faff077a513980f59a348
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177126
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This removes our temporary scaffolding support for JIT isolate groups
(which was implemented by creating a new isolate group, loading the
application kernel into it and then merging the heap into the original
isolate group - maintaining a different object store)
It makes all isolates within a group share the same object store, same
libraries and JITed code. It will be conservative to start with, only
allow running unoptimized code, etc.
We will gradually remove the restrictions imposed by this CL:
https://dart-review.googlesource.com/c/sdk/+/173970
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Tests using --enable-isolate-groups with JIT sharing.
Change-Id: I2bf69a6fe3c905067c4cec2e81613f731c52e5ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175302
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This should help with troubleshooting vm crashes caused by multiple mutator threads entering an isolate.
TEST=flutter/engine runtime_unittests that exhibits this flaky problem with DartIsolateTest.ValidLoadingUnitSucceeds
Change-Id: Ib503df844cceafa58882a695a1fe7ceaa88eaed4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174900
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
We serialize all changes to patchable call state to ensure we always
make progress (e.g. transition from Monomorphic -> Polymorphic).
Only if the miss handler actually needs to patch the patchable call do
we stop mutators - if it only updates ICData we don't have to do that.
=> In the future we might introduce a more clever mechanism to avoid
stopping mutators.
The CL also moves some locks from Isolate to IsolateGroup to ensure
all mutators use the same lock, since they operate on shared data
structures.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Existing isolate tests that --enable-isolate-groups.
Change-Id: I4a11a8b8bb65581c6aba11cdf73acdea0f24a502
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174469
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
With lightweights isolates enabled we need to ensure to update entries
in MetamorphicCache in sequence with mutual exclusion.
This CL adds appropriate locking for the MegamorphicCache.
Right now this is safe in AOT because the entire SwitchableCallMiss
handler runs with stopped mutators. A future CL will relax this. That
future CL will also move the megamorphic mutex from Isolate to
IsolateGroup, since the megamoprhic caches are shared within an isolate
group.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=CL is purely a refactoring.
Change-Id: I30305b04027d2bf9b4d5f6b1700bf158d38bdba7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174467
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Dart mutator threads cause update to runtime type feedback information
(e.g. ICData, MegamorphicCache). With multiple lightweight isolates
sharing JITed code, they will share the type feedback as well. That also
means multiple mutators can try to update type feedback at the same time
with the same (or different) feedback.
This means we can run into situations where we're trying to update type
feedback with information that's already there.
=> At a minimum we want to avoid adding duplicate entries to the ICData,
so we have to guard against that.
Since the actual backing store to ICData is immutable, we have two
choices:
* Let each thread read the current backing store, make a
copy-on-write, add the new entry and update ICData with new backing
store.
=> This can lead to an successful update being visible for a short
period and then disappearing.
* We can can ensure mutual exclusion when updating the backing store
of ICData, thereby making read+grow+write appear atomic.
=> This requires taking a lock but ensures we never hit the same
IC miss multiple times.
=> We take the latter approach for now.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=CL is purely a refactoring.
Change-Id: Ic3b2de61e25de0210323edd732424cc7d1178771
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174465
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
As part of making lightweight isolates work in JIT, we will need to
ensure that whenever a new isolate is spawned it will get it's initial
global field table populated.
In order to achieve this we make the isolate groups initial field table
the authoritive place where we
a) register initial static field values
b) serializer reads them from, deserializer writes them to
This allows us to also remove the `FieldLayout::initial_saved_value_`
that was present for both static and non-static fields. In reality this
initial saved value is only meaningful for static fields though it was
kept in memory as well as (de)serialized even for non-static fields.
The one place where it was actually used for non-static fields was
incorrect and should instead use `null`.
The removal of this field results in net removal of code in this CL.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Internal refactoring, relying on existing test coverage.
Change-Id: I088a87e2ea159bac7fa7f1f360da553d752e6569
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173263
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
As part of making lightweight isolates work in JIT, we will need to
ensure that whenever a new static field is loaded, it will get a new
slot on every isolate and the possibly initial static value is set in
all isolates's field state.
In order to achieve this we first move field registration out of
Field::New*() - to the place where the field is created and the initial
static field value is known.
In a future CL we will make a field registration be performed on all
isolates in a group.
TEST=CL is internal refactoring, existing test coverage.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I802ae55b841be173733dbd0ad3dbffeebd5c1889
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173260
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This option enables NNBD strong mode type checks and required parameter
checks even in NNBD weak mode. It is useful for testing partially
migrated code which cannot use sound null safety yet.
TEST=runtime/tests/vm/dart/strict_null_safety_checks_in_weak_mode_test.dart
Change-Id: I899e83d260fbed5b0fc5c1dcf0e42831d021bbe8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/169963
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
The Isolate.spawn() is part of our dart:isolate library implementation,
it should therefore preferrably live under runtime/lib folder.
This CL does that as well as removing some special message handling
logic by using the new `Dart_RunLoopAsync()` C API, which results in
net removal of code.
As a nice side-effect it also makes isolate spawning slightly faster due
to avoiding extra safepoint/vm<->native transitions.
Issue https://github.com/dart-lang/sdk/issues/44088
TEST=Changes existing implementation, have existing test coverage for it.
Change-Id: I00607a1436946552bbe12e8e23062e8f743d4f11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171731
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Dart_CreateLightweightIsolate API:
This API can be used by embedders to create a lightweight isolate
(inside an existing isolate group).
It is the analogous to Dart_CreateIsolateGroup - though taking a
parent isolate as parameter (inside whose IG we create a new isolate)
instead of taking kernel/snapshot data.
Right now this API works on AOT and returns an error in JIT, both cases
are covered by the test.
Dart_RunLoopAsync:
The API can be used by embedders to transfer ownership of an isolate to
the VM, which will take care of running the message handling loop and
shuts the isolate down once the last receive port has been closed.
It does allow listening to error/exit events generated by the message
loop implementation as well as allows setting errors-are-fatal,
effectively the same event-loop related parameters from the
`Isolate.spawn()` API, just in Dart.
It's the embedders responsibility to first launch initial dart code
which will take care of responding to events (i.e. directly/indirectly
open a receive port) - otherwise the isolate cannot be talked to and
would immediately shut down.
Since our vm/cc tests do support running in AOT, we use a hybrid
approach to test the functionality: We let a normal Dart test call a
small C wrapper using FFI, to create a lightweight isolate, run it on a
new thread and join that thread.
TEST=vm/dart{,_2}/isolates/dart_api_create_lightweight_isolate_test
Issue https://github.com/dart-lang/sdk/issues/36097
Closes https://github.com/dart-lang/sdk/issues/44088
Change-Id: Id77ba928793fdb517f6cb7e8130df98a0366ddd6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170983
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
When Dart invokes Isolate.spawn the Dart VM calls out to the embedder to
create an isolate (group) or initialize it (in case of lightweight
isolates).
* If the embedder doesn't implement this functionality or fails to
perform the creation/initialization, it will signal this failure
via the return value it gives to the VM in the call back
implementation (i.e. Dart_InitializeParams.create_group and
Dart_InitializeParams.initialize_isolate}).
* If the embeder sucessfully completed it's work, the VM owns the
isolate after the embedder call returns. The VM is then responsible
for running it.
It is an undocumented invariant atm that the embedder is responsible
to make the isolate runnable if it signals the VM that isolate was
sucessfully created/initialized.
=> If it does not do that, we have effectively an isolate leak.
=> Though right now seemingly all of our embedders to that correctly.
To avoid this unintentional isolate leak we make the isolate runnable
ourselves if embedder callback was successful but did not make it
runnable itself.
=> This also avoids unnecessary ceremony code in the embedders that
look like this:
Dart_ExitIsolate();
Dart_IsolateMakeRunnable(child);
Dart_EnterIsolate(child);
The implementation of `Dart_IsolateMakeRunnable()` had an untested and
unused code path that caused running the isolate (on a thread pool).
This is not documented and can lead to bugs because often the
embedders enter the isolate right after making it runnable (e.g. above
code sequence) - which would be racing with the spawned message handler
thread.
=> Furtunately our embedders are well behaved and make the isolate
runnable during the callback.
=> As a safeguard we'll make `Dart_IsolateMakeRunnable()` return an
error if it's called outside the callback (which we can detect by
the presense of a spawn state)
Issue https://github.com/dart-lang/sdk/issues/44088
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Changes internal details of implementation which is already covered by tests.
Change-Id: Ieef316cc0807d99f2fcb1fbd56bbc9c41e904ba8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/170882
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This CL adds acquisiton of write lock and check for whether write lock is held when updating class functions, primarily populated during class finalization. Read locks will be added in successive CLs, so is extending of the locks coverage to all aspects of program structure changes.
Bug: https://github.com/dart-lang/sdk/issues/36097
Change-Id: I3dba6bc23db4e45599a20717226210f12e7fd2b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168140
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Alexander Aprelev