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>
These tests are slow and have flaky timeouts on dartkp-*-simarm and
dartkp-*-simarm64 bots. On dartkp-linux-release-simarm64 this test
recently becomes non-flaky timeout. Trying to increase the time
allocated to run those tests.
Change-Id: I1252b19fa7dbf7e592043a76c1402a2454793b16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184501
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This is a preparation CL to enable actually sharing JIT'ed code between
isolates within the same isolate group.
We start with conservative settings, disabling various compiler
optimisations. We will lift those restrictions step-by-step.
Since this is guarded by FLAG_enable_isolate_groups it will not affect
any production code. Only individual tests which opt-in via the flag.
TEST=Existing tests opt'ing into --enable-isolate-groups.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I05c4151116a8516f92c76b4d57f2c7fb725168ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173970
Reviewed-by: Vyacheslav Egorov <vegorov@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>
pkg/vm_snapshot_analysis is used in
runtime/tests/vm/dart/v8_snapshot_profile_writer_test.dart
which can run on sharded bot configurations such as
dartkp-weak-asserts-linux-release-x64.
Change-Id: Ie843a38069394f42be79b432d8a71bbf6d472073
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/159322
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
We create the parameter names array when loading the
FunctionDeclaration, but the required parameter flags are only set later
when we load the Code declaration. If there's an intermediate use of the
Function object that copies the required parameter flags, like creating
an ImplicitClosureFunction when loading a tearoff stored in the object
pool, there will be no set flags at that point.
Add a copy of the parameter flags to the FunctionDeclaration so the
required flags can be set at the same time as the parameter name and
type to avoid this scenario.
To avoid adding unneeded flags to the kernel bytecode, we only serialize
the parameter flags needed for each declaration, so FunctionDeclaration
and ClosureDeclaration only contain the required flag, and Code contains
all flags _but_ the required flag.
There are no trybots for strong mode + bytecode, but manually checked
by running the following on the main branch (cherry-picking the
test_matrix.json changes) and this branch:
python tools/test.py \
-n dartkb-mixed-strong-linux-release-x64,dartkb-interpret-strong-linux-release-x64 \
tests/language/nnbd/required_named_parameters/missing_required_argument_dynamic_test.dart
Cq-Include-Trybots: luci.dart.try:vm-dartkb-linux-release-simarm64-try,vm-dartkb-linux-release-x64-try
Change-Id: Ic75b831d5ceed08154e2c61b8f64461705558653
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/162501
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Concrete cids are 16-bit unsigned values, but Slot::cid_ was erroneously
declared as a signed value - which causes issues in program with large
amount of classes once it flows into variables of larger signed types
(classid_t or intptr_t).
Fixes b/162922506
Fixed: 162922506
Change-Id: Id116273aa34dbf6886c352427cf4565fc5dc2293
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157487
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Note: This is a reland of https://dart-review.googlesource.com/c/sdk/+/150343
Adds a new SDK hash to kernels and the VM which is optionally checked
to verify kernels are built for the same SDK as the VM.
This helps catch incompatibilities that are currently causing
subtle bugs and (not so subtle) crashes.
The SDK hash is encoded in kernels as a new field in components.
The hash is derived from the 10 byte git short hash.
This new check can be disabled via:
tools/gn.py ... --no-verify-sdk-hash
This CL bumps the min. (and max.) supported kernel format version,
making the VM backwards incompatible from this point back.
This also bumps the min. and current ABI version.
Bug: https://github.com/dart-lang/sdk/issues/41802
Change-Id: I2f85945045a603eb9dcfd1f2c0d0d024bd84a956
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152802
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This was fixed by running:
dart pkg/status_file/bin/normalize.dart \
-w runtime/tests/vm/vm.status
The linter can be run to verify the result:
tools/sdks/dart-sdk/bin/dart \
pkg/status_file/bin/lint.dart \
runtime/tests/vm/vm.status
Change-Id: I99d35f900b2d4ff5c6da332ed8fe347e2a7ac96d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153204
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
This test flakily times out on MacOS (the FATAL(), which calls abort(),
somehow is stuck) and spams the flakiness dashboard.
Though the test shouldn't even run on MacOS, since we don't support
--dual-map-code on non-linux/fuchsia.
Change-Id: I6a93b825c3021028a43b46a8bf33f84e34838211
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/153142
Reviewed-by: Clement Skau <cskau@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
AOT transformations (mixin deduplication and TFA tree shaker) were
using CanonicalName.unbind() in order to make sure that kernel
writer will not be able to write dangling references to the deleted
classes or members (to detect such dangling references earlier).
This conflicts with lazy reading from a kernel file if --from-dill
option is used: lazy reader may read a reference to such class after
unbind() and it creates a new Reference object for such canonical name.
This causes crash later when the fresh Reference is used as it doesn't
have Class node filled in.
The solution is to avoid calling CanonicalName.unbind().
Instead, it is enough to nullify node.reference.canonicalName, which
won't break CanonicalName.reference used by lazy reader.
This crash can be reproduced on tests/language_2/vm/regress_flutter_55345_test.dart
if it is compiled in AOT mode using 2-step kernel generation.
Bug: b/158853113
Change-Id: Ib2004dbbbda85d9f56adc56b48882f4ef08869a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151120
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The newly added --worker-thread-priority can be used by users as an
opt-in to set the thread priority / nice value.
It is the responsibility of the user to ensure that the process has the
right to change the priority to the given value. Failure to set the
priority will be fatal.
See b/154918152
Change-Id: I3b3791e88b6ddf4fa6e39e4587f7fe1ab4d2312f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150560
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This option can be used to split AOT kernel generation into two rounds:
* The 1st round uses CFE to parse source files and generate intermediate
dill file in *non-AOT* mode.
* The 2nd round loads intermediate dill file and applies AOT global
transformations, then generates final dill file.
Each round is faster than one-shot generation of a dill file in AOT mode.
In order to use this 2-round compilation, command
gen_kernel <other-options> --aot -o output.dill main.dart
should be replaced with the following 2 commands:
gen_kernel <other-options> --no-aot -o intermediate.dill main.dart
gen_kernel <other-options> --aot --from-dill intermediate.dill -o output.dill main.dart
Bug: b/158101962
Change-Id: I2d4deef45b50eab11df47f4a372598e6cf1d0edf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/150272
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This change mechanically copies
runtime/tests/vm/dart -> runtime/tests/vm/dart_2
in preparation for the migration of runtime/tests/vm/dart to NNBD.
Corresponding statuses in vm.status are duplicated.
Added vm_nnbd builder tag for NNBD bots.
vm/dart/* tests are allowed to run only on vm_nnbd builders.
vm/dart_2/* tests are allowed to run only on non-vm_nnbd builders.
Issue: https://github.com/dart-lang/sdk/issues/41314
Change-Id: I079da92da17960605f37c1c0e28e48362b236739
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149485
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Before this change we would replace unboxed definitions (those with
representation not equal to kTagged) which is too loose and causes issues
in subsequent passes, which assume that replacements have normalised
representation.
After this change we make sure that replacement has a matching
representation.
Closes https://github.com/dart-lang/sdk/issues/35371
Fixes https://github.com/dart-lang/sdk/issues/41971
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try
Change-Id: I48543893562acf4f8516651196eba7c0c0769a22
Fixed: 35371,41971
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103139
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
If a custom embedder does not use the VM's thread pool implementation
(1) but instead installs a custom message handler and invokes that
message handler on possibly unlimted number of threads, those mutator
threads will be constantly fighting to obtain TLABs.
To avoid this, the VM will ensure that only a limited number of mutators
can execute at the same time. The limit is the same as we use for
determining the VM's mutator thread pool.
In order to test this, we simulate such an embedder by disabling the
mutator pool limit, thereby allowing unlimited number of thread pool
workers.
=> The added test would timeout without without the new limit imposed
by this CL.
(1) Which has a maximum size adjusted based on TLAB size and new space size.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I6d459f85fbeb3e4b1d756b752853157e40097271
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148121
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
To avoid deadlock scenarios where an application runs N isolates on a
thread pool with T threads (T < N) where all scheduled T isolates will
do FFI call and block. That prevents any other isolates from executing.
To avoid such a scenario we add support for the isolate-group specific
thread pool to dynamically increase the maximum size if a worker is
running a isolate mutator thread, which calls to C which exits the
isolate.
=> While such an isolate is descheduled but still occupies a thread
pool worker we temporarily incrase the maximum size of the thread pool.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: Id61c39b06766da11f76d607ac7cbe8a8e623f250
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148120
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Some isolate might get Run message and start sending data(Tree) to a receiver before that receiver got Run message.
Fixes dartbug.com/41813
Change-Id: Ifdf1a44d3a2f955f5919d3fd63bf97e9b3317388
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147329
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
To enable our tests to spawn a new isolate in a new group, this CL
adds a `{bool newIsolateGroup}` parameter to the internal
`Isolate._spawnFunction` native and moves that native to
`dart:_internal`, thereby allowing runtime/tests/vm/dart/* to access it.
It also adds various tests for lightweight AOT isolates, exercising
GC, communication, spawning, ...
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I3940c30fb43d2475c58e6be78507da74ce64b60d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145941
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Symbolic and non-symbolic stack traces had separate ToCString
implementations with the same general structure, but those
implementations diverged enough to cause issues in certain async stack
modes. They are now merged, with the --dwarf-stack-traces-mode flag
checked where appropriate within the merged method.
Also, now non-symbolic stack traces do not include frames for Code with
invisible Function owners unless the flag --show-invisible-frames is
enabled. With this change, pkg/native_stack_traces no longer needs to
guess at which frames corresponding to Dart code should be treated as
internal.
Tested by adding --dwarf-stack-traces version of the tests
in runtime/tests/vm/dart/causal_stacks.
Fixes https://github.com/dart-lang/sdk/issues/41578
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try
Change-Id: I41a887129616c88acd7729492addf7364d95df33
Bug: 41578
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/143816
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Ben Konyi