Previously, we only stored a reference to the originating Typedef declaration
and is thus loosing the originating type arguments. We need these type arguments
in various places, including diagnostics and bounds checks.
Note: this CL maintains backwards compatibility wrt to the Dart API of
FunctionType. I'll update the API in a follow-up CL.
Change-Id: I896ce3c3b4522d542a82c5036f8a17ee098143dc
Reviewed-on: https://dart-review.googlesource.com/c/81367
Commit-Queue: Peter von der Ahé <ahe@google.com>
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This makes us report the following error
* in JIT:
Unhandled exception:
'test.dart': error: Type arguments must be instantiated in partial instantiation.
#0 main (...)
...
* in AOT:
test.dart:7:28: Error: The type '#lib1::C::T' is not a constant, only instantiated types are ...
const C({this.callback = _defaultCallback});
^
test.dart:7:17: Context: While analyzing:
const C({this.callback = _defaultCallback});
^
test.dart:5:37: Error: The type '#lib1::C::T' is not a constant, only instantiated types are ...
void foo([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:5:33: Context: While analyzing:
void foo([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:11:38: Error: The type '#lib1::bar::T' is not a constant, only instantiated types are ...
void bar<T>([dynamic Function(T) f = _defaultCallback]) {}
^
test.dart:11:34: Context: While analyzing:
void bar<T>([dynamic Function(T) f = _defaultCallback]) {}
Issue https://github.com/dart-lang/sdk/issues/32912
Change-Id: I05c7019119a50a9cc38939d9cb41aeaa06c853bc
Reviewed-on: https://dart-review.googlesource.com/c/81278
Auto-Submit: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This reverts commit daae20d32e.
Reason for revert:
The kernel-precomp bots are seeing this error:
../../runtime/vm/object.h: 3134: error: Handle check failed: saw 2249186640 expected Function
Not sure what that is yet, but reverting to get bots green again while I investigate.
Original change's description:
> [vm/compiler] Use loop framework for AOT inline heuristics
>
> Rationale:
> Without proper execution counters, the inline AOT inliner
> marks every call site "cold", effectively disabling inlining
> altogether. This change introduces loop-based static heuristic
> that assumes statements nested inside loops are executed more
> frequently. This results in more inlining.
>
> Note:
> Conservative version is used for now which yields
> more performance without increasing code size too much.
> There is still a lot of performance left at the table
> which we could exploit if we fine tune heuristics
> regarding code size.
>
> Bug:
> https://github.com/dart-lang/sdk/issues/34473
> https://github.com/dart-lang/sdk/issues/32167
>
>
> Change-Id: I86ba60f93bdab363cd22ab6bdbcf6688f2042fea
> Reviewed-on: https://dart-review.googlesource.com/c/81187
> Commit-Queue: Aart Bik <ajcbik@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
TBR=vegorov@google.com,alexmarkov@google.com,ajcbik@google.com
Change-Id: If5ca82966966ebef4ec0b4e921515d23f6bd492b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/81335
Reviewed-by: Aart Bik <ajcbik@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
Rationale:
Without proper execution counters, the inline AOT inliner
marks every call site "cold", effectively disabling inlining
altogether. This change introduces loop-based static heuristic
that assumes statements nested inside loops are executed more
frequently. This results in more inlining.
Note:
Conservative version is used for now which yields
more performance without increasing code size too much.
There is still a lot of performance left at the table
which we could exploit if we fine tune heuristics
regarding code size.
Bug:
https://github.com/dart-lang/sdk/issues/34473https://github.com/dart-lang/sdk/issues/32167
Change-Id: I86ba60f93bdab363cd22ab6bdbcf6688f2042fea
Reviewed-on: https://dart-review.googlesource.com/c/81187
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This is a reland of 6ba3e55ecc
The issue was that SlowTypeTestStub used in precompiled mode did not handle a
Smi instance before calling the Subtype2TestCache stub which does not support
it. See PatchSet 2 for the fix.
Is there a more efficient solution?
Original change's description:
> [VM runtime] Support Smi instances in type test cache.
>
> This adds SubtypeTestCache-based optimizations for type tests against
> * dst_type = FutureOr<T> (when T=int/num)
> * dst_type = T (when T = FutureOr<int/num>)
>
> Remove dangerous LoadClass pseudo assembler instruction (does not work for Smi).
> Handle instantiated void in type tests (along with dynamic and Object).
>
> Change-Id: I0df0fc72ff173b9464d16cc971969132b055a429
> Reviewed-on: https://dart-review.googlesource.com/c/81182
> Commit-Queue: Régis Crelier <regis@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
Change-Id: I333ca47aebd7f0b663059ab6afc5d1cd8d7d5210
Reviewed-on: https://dart-review.googlesource.com/c/81320
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
dart binary would instantiate CrashpadClient if DART_CRASHPAD_HANDLER
and DART_CRASHPAD_CRASHES_DIR environment variables are set.
- DART_CRASHPAD_HANDLER should contain the path to the crashpad_handler
binary that would handle the crash and write minidump;
- DART_CRASHPAD_CRASHES_DIR should contain the path to the crashpad database
which would be used to store minidumps.
Rewrite --copy-crash-dumps support on windows to use Crashpad integration
instead of editing Windows registry.
Embedding crashpad required to roll a new zlib version because Crashpad
depends on the zlib. This version of zlib is buildable with its own
BUILD.gn so our custom BUILD.gn is removed.
Change-Id: I048aad16b234e1d750f0a24782b04e3b6e19703d
Reviewed-on: https://dart-review.googlesource.com/c/81007
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This adds SubtypeTestCache-based optimizations for type tests against
* dst_type = FutureOr<T> (when T=int/num)
* dst_type = T (when T = FutureOr<int/num>)
Remove dangerous LoadClass pseudo assembler instruction (does not work for Smi).
Handle instantiated void in type tests (along with dynamic and Object).
Change-Id: I0df0fc72ff173b9464d16cc971969132b055a429
Reviewed-on: https://dart-review.googlesource.com/c/81182
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit 89c845eba2.
Reason for revert: Seems to cause ASAN failures
Original change's description:
> [VM] Fix for issue 34839 - Dart_Cleanup may hang while shutting down
> the service isolate.
>
> The service isolate request for shutdown uses a Dart level message
> for exiting the isolate, this shuts down the isolate but does not
> completely bring the isolate down if there are some open ports. We
> have a timer isolate started in the VM isolate and if the shutdown
> happens soon enough this port is still open.
>
> Change-Id: Icfa07c91b8692eb76ba8502063cf6f5cf04832a5
> Reviewed-on: https://dart-review.googlesource.com/c/81200
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
> Commit-Queue: Siva Annamalai <asiva@google.com>
TBR=rmacnak@google.com,asiva@google.com
Change-Id: I0fd4472d277a380b739e602aa3910cc1f96ed89e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/81223
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
the service isolate.
The service isolate request for shutdown uses a Dart level message
for exiting the isolate, this shuts down the isolate but does not
completely bring the isolate down if there are some open ports. We
have a timer isolate started in the VM isolate and if the shutdown
happens soon enough this port is still open.
Change-Id: Icfa07c91b8692eb76ba8502063cf6f5cf04832a5
Reviewed-on: https://dart-review.googlesource.com/c/81200
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
In order to simplify testing and performance comparison, it is useful to
be able to run a command-line VM with a Dart source and use bytecode pipeline.
The bytecode generation is turned on in kernel service if --enable-interpreter
or --use-bytecode-compiler VM option is specified.
Change-Id: I6eb222b4df1721075c08d5f48c6d299ec779cb8c
Reviewed-on: https://dart-review.googlesource.com/c/80960
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Rationale:
Rather than relying on a separate loop detector, rely
on the new loop framework, which avoids code duplication
and ensures any improvement in loop detection/handling
will benefit this phase too. Note, most of the time, the
same loops are discovered with a few exceptions (which
is okay, since this is "just" heuristic usage). This CL
also simplifies loop detection a bit.
https://github.com/dart-lang/sdk/issues/34473
Change-Id: I1a1b19b99a698c74822473d2a1fe370287c1ade4
Reviewed-on: https://dart-review.googlesource.com/c/80523
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This change allows devs embedding the VM in e.g. a server to e.g. export VM metrics as part of their server health metrics.
Change-Id: I7a86a3ad98b900d30d9b7f5d19fa77f1705610c6
Reviewed-on: https://dart-review.googlesource.com/c/74723
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Clement Skau <cskau@google.com>
The mutator thread structure is kept alive until the death of the
isolate. Yet the mutator thread does not have to be scheduled all the
time. A native call, for example, can suspend the isolate via
Dart_ExitIsolate to perform other work.
This particular flaky crash had precisely this problem: The mutator
thread suspended itself with an IsolateSaver scope (which uses Dart_ExitIsolate)
and invoked Dart_NewNativePort. While at the same time the background
compiler for that isolate triggered an oldspace allocation, which
triggered a marking task. The marker task needs to traverses the mutator
stack and hits a frame with a deoptimization marker, which causes it to
access the mutator thread's isolate pointer, which was incorrectly NULL.
Fixes https://github.com/dart-lang/sdk/issues/34748
Fixes https://github.com/dart-lang/sdk/issues/34323
Change-Id: I80440856f72b3c194a516084ddc254b2e56740d8
Reviewed-on: https://dart-review.googlesource.com/c/80860
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When GC is visiting pointers, it scans mutator thread even if it is not
active. It could happen if a thread has (temporarily) exitted isolate.
In such case, stack frame iteration would not find interpreter and
would not recognize interpreter frames. An attempt to visit interpreter
frame as non-interpreter causes crashes/assertions.
The fix is to move interpreter from Isolate to Thread. This way
interpreter is available for stack walking even if thread doesn't have
isolate.
This is the re-land of https://dart-review.googlesource.com/c/sdk/+/80760
with the fix for precompiler failures.
Change-Id: I1fa054d43b86aa49c48490d0951b876b7c7218d8
Reviewed-on: https://dart-review.googlesource.com/c/80782
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
When sorting classes during app-jit training we permute the class ids.
This makes canonical hash codes which depend directly (or indirectly) on
class ids change. We already clear out the cached canonical hash codes
in type-related instances in the heap.
Though the cid renumbering makes the non-cached canonical hashcodes of
other objects, such as canonical Instance and Array objects, also change.
This means any data structures which use canonical hash codes of
type related objects or Instance/Array objects need to re-hash.
-> This CL makes us rehash the constant tables after cid renumbering.
Fixes https://github.com/dart-lang/sdk/issues/34849
Change-Id: Icfb5add3f14e2c62c5bca94f296133121ad0bc55
Reviewed-on: https://dart-review.googlesource.com/c/80801
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reverts commit a0cc3e2684.
Reason for revert: broken precompiler bots
Original change's description:
> [vm/interpreter] Fix interpreter frame recognition in stack walking
>
> When GC is visiting pointers, it scans mutator thread even if it is not
> active. It could happen if a thread has (temporarily) exitted isolate.
> In such case, stack frame iteration would not find interpreter and
> would not recognize interpreter frames. An attempt to visit interpreter
> frame as non-interpreter causes crashes/assertions.
>
> The fix is to move interpreter from Isolate to Thread. This way
> interpreter is available for stack walking even if thread doesn't have
> isolate.
>
> Change-Id: Iff12ce7391b19a6f87bd4fac94137cba5623dfb9
> Reviewed-on: https://dart-review.googlesource.com/c/80760
> Reviewed-by: Régis Crelier <regis@google.com>
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
TBR=rmacnak@google.com,alexmarkov@google.com,zra@google.com,asiva@google.com,regis@google.com
Change-Id: Ic4d73536eadb6601ee323918c65f5f2b2b2b2418
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/80781
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
When GC is visiting pointers, it scans mutator thread even if it is not
active. It could happen if a thread has (temporarily) exitted isolate.
In such case, stack frame iteration would not find interpreter and
would not recognize interpreter frames. An attempt to visit interpreter
frame as non-interpreter causes crashes/assertions.
The fix is to move interpreter from Isolate to Thread. This way
interpreter is available for stack walking even if thread doesn't have
isolate.
Change-Id: Iff12ce7391b19a6f87bd4fac94137cba5623dfb9
Reviewed-on: https://dart-review.googlesource.com/c/80760
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Currently symbolization is implemented through heap iteration - and
iterating a heap, which in turn requires creating HeapIterationScope and
extremely sophisticated operation that involves taking multiple locks
and waiting for threads to safepoint. This is too complex to be used
from the signal handler which is invoked in case of a crash - it can
lead to recursive crashes or worse - deadlocks.
For now we simply disable symbolization of Dart frames. In the future
we should switch symbolization to use an off the heap data structure
which can be accessed from a signal handler.
Fixes https://github.com/dart-lang/sdk/issues/34814
Bug: 34814
Change-Id: Ib905acafedf64a1b314374b65a99880f43e79b77
Reviewed-on: https://dart-review.googlesource.com/c/80623
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
ClassFinalizer::VerifyBootstrapClasses invokes Scavenger::VisitObjects
on the vm_isolate's heap without taking any locks. In general it is
safe because vm_isolate is fully immutable and is never entered by
a mutator thread. However we temporarily enter vm_isolate in
Dart::Cleanup - which violates this assumption.
The crash usually manifests as a null pointer dereference in
Scavenger::FlushTLS (inlined into Scavenger::VisitObjects):
// Note: heap_->isolate() is vm_isolate.
void Scavenger::FlushTLS() const {
if (heap_->isolate()->IsMutatorThreadScheduled()) {
Thread* mutator_thread = heap_->isolate()->mutator_thread();
mutator_thread->heap()->new_space()->set_top(mutator_thread->top());
}
}
There is no locking here, so if this is executed concurrently with
Dart_Cleanup then this code would see true value from
IsMutatorThreadScheduled() and null pointer from mutator_thread() -
which would lead to a crash.
We fix the race by reordering actions in the Dart::Cleanup - wait for
all isolates to shut down before entering vm_isolate - this way no other
isolate would see that vm_isolate being attached to a mutator thread.
Fixes https://github.com/dart-lang/sdk/issues/34750
Bug: 34750
Change-Id: Ia6088c1b78d1b56f3fe780c68dfd9dcad1e7a8b8
Reviewed-on: https://dart-review.googlesource.com/c/80449
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Given
```
import 'dart:isolate';
import 'dart:async';
void func(_) {
throw new Exception('bad news');
}
void main() {
ReceivePort receivePort;
receivePort = new ReceivePort()..listen((_) { receivePort.close(); throw "more bad news"; } );
Isolate.spawn(func, [], onExit: receivePort.sendPort);
}
```
Before this change only 'more bad news' will be printed on the stderr, after this change both 'bad news' and 'more bad news' will be printed out.
Before:
```
$ out/ReleaseX64/dart $DH/exc.dart
Unhandled exception:
more bad news
```
After:
```
$ out/ReleaseX64/dart $DH/exc.dart
Isolate is shutting down with the error: Unhandled exception:
Exception: bad news
Unhandled exception:
more bad news
```
Bug: https://github.com/dart-lang/sdk/issues/26626
Change-Id: Ief15f254837d9a02b93a6da655051fccf7c3dd2e
Reviewed-on: https://dart-review.googlesource.com/c/52680
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
The stack slot which is reserved for the result of runtime call
could contain garbage when doing the call, but it could be visited by GC
before a valid value is assigned there.
Found using --verify_on_transition flag.
Change-Id: I3968d23965806874a5ca53f0ac036c156fb53ca5
Reviewed-on: https://dart-review.googlesource.com/c/80044
Commit-Queue: Zach Anderson <zra@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Setting WasCompiled on a function after unoptimized compilation in the
background thread could race with other modifications of function tags.
To avoid this potential problem, setting of WasCompiled is moved to
FinalizeCompilation which is called at safepoint.
This is a possible fix for flaky assertion failure
../../runtime/vm/compiler/jit/compiler.cc: 901: error: expected: !optimized || function.WasCompiled()
on dartkb/debug bots.
Change-Id: Ia38ddf892438be3314e181cd77c8f8d6cf69978d
Reviewed-on: https://dart-review.googlesource.com/c/80381
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
mDNS queries (and many other local queries) should be allowed to set
their TTL to 255. This patch enables that on all platforms.
On macOS in particular, a system service reserves the mDNS port. The
socket option SO_REUSEPORT is required in addition to SO_REUSEADDR to
successfully bind there; the flag is also supported on Linux, so this
patch allows it to be used there as well (but prints an error message if
it's used on any other platform).
I could use some guidance as to tests for this - is it support availble
for running tests only on specific platforms?
Bug: https://github.com/dart-lang/sdk/issues/34799 and
Change-Id: I29b620d8ec04343f356a8171bae3d385ddfa9564
https://github.com/dart-lang/sdk/issues/34782
Reviewed-on: https://dart-review.googlesource.com/c/80082
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Vyacheslav Egorov