Since allocation instructions can throw OOM exceptions, they require
deopt information. In general it's rather hard to test that this deopt
information is correct.
In order to test this, this CL makes those IR instructions support lazy
deopt and add tests that exercise this deopt sequence, thereby ensuring
the deoptimization environment is correct.
Issue https://github.com/dart-lang/sdk/issues/45213
TEST=New vm/dart_2/isolates/deopt/*_test.
Change-Id: I6a02dcf5a0c47636f1f0aa4cd8cc0d2b4f032ca0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192687
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
NullIsAssignableTo only takes the type to check for nullability.
However, while a type parameter may itself be non-nullable, its
instantiation with a nullable type is nullable.
Thus, this CL adds type instantiation before runtime uses of
NullIsAssignableTo in Function::DoArgumentTypesMatch.
Fixes https://github.com/dart-lang/sdk/issues/45270
TEST=vm/dart/regress_45270
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-release-simarm64-try,vm-kernel-precomp-nnbd-linux-release-simarm_x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-nnbd-linux-release-ia32-try,vm-kernel-nnbd-linux-release-simarm-try,vm-kernel-nnbd-linux-release-simarm64-try
Change-Id: Iaefffe9ab6d4d3ad889c4962489b2153d2bbaee1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190443
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
For async closure parsed_function_ could be an outer function
which is unrelated to the closure. So, ScopeBuilder should not
attempt to mark parameters of parsed_function_ with
set_is_forced_stack() if it sees kSyncYielding FunctionNode.
Parameter variables might not be even allocated if
async closure is used inside an instance field initializer
and parsed_function_ is a constructor.
TEST=runtime/tests/vm/dart/regress_45306_test.dart
Fixes https://github.com/dart-lang/sdk/issues/45306
Change-Id: I1b0082cb0e217039c43f19b35d77190493069edc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/191325
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Instead of being part of the --trace-precompiler output, there is
is a new flag --write-retained-reasons-to=<path>.
To allow for non-functions to have reasons for retention, the
JSON objects in the array now have one additional field:
* type: a string, the C++ type of the Dart object.
This CL also wraps all the machinery in a RetainedReasonsWriter
class instead of putting it in the Precompiler interface.
TEST=vm/dart{,2}/use_trace_precompiler_flag
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try
Change-Id: Ifa40ac64fdcbdad5114499425c7f8b08e327fa76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190525
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Unfortunately, we never capitalized on having it (e.g. original plan was
to use it for writing tests, among other things) and continuing to
maintain it does not make sense.
TEST=ci
Change-Id: I02b2c35149298a295aa0de75916d48434d4a3ea9
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,pkg-linux-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190220
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
To get this information, enable --trace-precompiler.
There are two version of the output: a human readable version
and a JSON version (preceded by 'JSON for function decisions:')
for easier tabulation. The JSON version is an array of objects,
where the fields of the object are as follows:
* name: a string, the function name
* kind: a string, the function kind
* retained: a boolean, whether the function was retained
* reasons: an array of strings, reasons for retaining
(only for retained objects)
TEST=vm/dart{,_2}/use_trace_precompiler_flag_test.dart
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try
Change-Id: I9b006a49e1410a832950a1bd29a0abaabe9431f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190000
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The deoptimization environment of AssertAssignable should not have it's
inputs in it, since those get poped before the call to the
TypeTestingStub.
A lazy deopt should therefore continue in unoptimized code after the TTS
call, without the inputs.
This was discovered by running many lightweight isolates concurrently on
the JIT.
To simplify a regression test we'll add new VM flags that can trigger
deoptimization on any runtime call (optionally filtered by name of
runtime call).
We can use this mechanism to possibly discover more bugs of the same
kind.
Closes https://github.com/dart-lang/sdk/issues/45207
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=runtime/tests/vm/dart{,_2}/regress_45207_test
Change-Id: Ib713fa8be5914eaf4c7395d2e1d8dd88714f1ce2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/189202
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The CFE can invoke transformations despite having compile-time errors.
The async transform was crashing the compiler if it hits for-in
iterables that have an invalid type or never type.
In case of an invalid type, the program has a compile-time error and
won't be able to run propertly. So we'll replace the entire for-in with
an invalid expression statement if the iterable is an invalid
expression.
In case of a never type, the program should compile fine, which this CL
also fixes.
This makes the newly added tests no longer result in DartkCrash but
rather in a compile-time error (invalid expression) or runtime-error
(never type).
Closes https://github.com/dart-lang/sdk/issues/45014
Change-Id: Ic50f68400b67b57dd4a2c0a125b08f0f3e0d8dd6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188463
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Johnni Winther <johnniwinther@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>
This optimization does not make sense in AOT and can actually cause
AOT compiler to segfault because it expects environment to be
attached to AssertAssignable instructions which is not always
the case on AOT compiler.
Fixes https://github.com/flutter/flutter/issues/76919
TEST=vm/cc/TypePropagator_RegressFlutter76919,vm/dart{,_2}/regress_flutter76919
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try
Change-Id: I8f4314d7dac276833a9050bba835616b670a88d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188281
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Since the flag is now enabled by default, there should be no mention of it.
There are still some uses in front_end/testcases that are not just removable
(it also uses `no-non-nullable`). There migth be more uses that are not
as easily found as grepping for `--enable-experiment
Removes two VM tests where fixing them meant they were just duplicating
the corresponding non *_2/ tests.
Fixes#44941
TEST= Large number of tests chaged.=(no-)?non-nullable`.
Change-Id: Ief755981ccde9a5482fcdf408c2929c74433a710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/183688
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@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 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>
This converts `return e` in async methods in opt-in libraries into
return let v = e in v is Future<FTV> ? await v ; v
where FTV is the future value type of the enclosing function.
Closes#44395Closes#44396Closes#44397Closes#44399
TEST=existing tests
Change-Id: I59687039bfe4a97ffdaa55ac0f193ca4fb208f44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175310
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
When a function type does not describe the signature of a function (e.g. when it just describes a function type literal), the names of the type parameters are not relevant and can be replaced by canonical names allowing proper canonicalization of type literals.
TEST=fixes upcoming language/nnbd/const/type_literals_test
Change-Id: I62924ef619ae3f5a2fe5964f45c8d60990f3aa69
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179060
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This is a step toward deferring literals, to effectively split binary size for libraries that are more data than code, such as localizations. Bare instructions mode still has all constants in the root snapshot because it has one global ObjectPool.
dart2js+analyzer product X64 non-bare:
app.so 10072728 -> 8479824 (-15.8%)
app.so-2.part.so 14074512 -> 15016976 (6.69%)
app.so-3.part.so 9225936 -> 9888984 (7.18%)
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/41974
Change-Id: If61f6156e3fc2dd539331335b3bf0458102b7c75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/168991
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This does not include enabling the FFI on Fuchsia. So these tests will
fail without the dependent CL.
This CL adds an `all_positive.dart` test file to be packaged in the
.far file, such that it is easier to run all FFI tests in one go.
We don't run tests on the bots, but we do build this test package on
the bots.
To build the .far files locally:
```
tools/build.py --os=fuchsia -m debug fuchsia_ffi_test_package
tools/build.py --os=fuchsia -m debug -a arm64 fuchsia_ffi_test_package
```
Issue: https://github.com/dart-lang/sdk/issues/44434
Change-Id: Iec418e0c10d77afbf811fb83151664bcc2710b99
Cq-Include-Trybots: luci.dart.try:vm-fuchsia-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175484
Reviewed-by: Liam Appelbe <liama@google.com>
Martin Kustermann