Before this CL, debugging code like this:
```
import "dart:developer";
main() {
Foo foo = new Foo();
foo.bar<dynamic, dynamic>(1, 2);
}
class Foo {
bar<A, B>(A a, B b) {
debugger();
print("a: $a; b: $b");
}
}
```
and trying to print for instance `a` or `b` when the debugger is stopped
in `bar` (e.g. `p a`) would yield a wrong result. I.e., this happends
when debugging methods taking type arguments, but where the type
arguments are all `dynamic`.
This also surfaces when hovering variables in e.g. VSCode with the
Dart Code plugin.
Fixes: #34353.
Change-Id: Iddf1ed119700fea61a0e29eb6ad763a8d2b657a0
Reviewed-on: https://dart-review.googlesource.com/74583
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
We need to block interrupts while evaluating pragmas to prevert reentrant class finalization.
Original revision is in patchset 0.
Change-Id: I872cec4eaf4ca85567c9657c458ed39c8b2e30de
Cq-Include-Trybots: luci.dart.try:vm-kernel-win-release-x64-try, vm-kernel-optcounter-threshold-linux-release-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-release-simarm-try, vm-kernel-precomp-linux-release-simarm64-try, vm-kernel-precomp-linux-release-x64-try, vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/73160
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When clicking the "toplist by retained memory" button in Observatory
it always asks to find 10 objects of a specific size.
The previous implementation did this by taking all objects (millions if
using a lot of memory), sorting it (O(n log n)), filtering it (O(n)),
and ".take"ing the 10 we wanted. Total runtime should be O(n log n)
where n is the number of objects in the heap.
This CL optimizes this for the (to my knowledge) only case there exists,
and instead, while iterationg over all elements (O(n)) keeps a sorted
working list of the top m objects (this is 10 for all intents and purpose
as far as I can see; I've if-cased it to be at most 20). Total runtime
should be O(n log m) where n is the number of objects in the heap and m
is the requested number, which - as said - is at most 20, i.e. a constant,
maying that the runtime is more like O(n).
Instrumenting the code slightly to measure how long it takes:
```
diff --git a/runtime/observatory/lib/src/repositories/top_retaining_instances.dart b/runtime/observatory/lib/src/repositories/top_retaining_instances.dart
index 400ac1427ed..b7e5c429fac 100644
--- a/runtime/observatory/lib/src/repositories/top_retaining_instances.dart
+++ b/runtime/observatory/lib/src/repositories/top_retaining_instances.dart
@@ -7,6 +7,8 @@ part of repositories;
class TopRetainingInstancesRepository
implements M.TopRetainingInstancesRepository {
Future<Iterable<M.RetainingObject>> get(M.IsolateRef i, M.ClassRef c) async {
+ Stopwatch stopwatch = new Stopwatch()..start();
+ try {
S.Isolate isolate = i as S.Isolate;
S.Class cls = c as S.Class;
assert(isolate != null);
@@ -18,5 +20,9 @@ class TopRetainingInstancesRepository
return (await Future.wait(
snapshot.getMostRetained(isolate, classId: cls.vmCid, limit: 10)))
.map((object) => new S.RetainingObject(object));
+ } finally {
+ int ms = stopwatch.elapsedMilliseconds;
+ print("TopRetainingInstancesRepository took $ms ms.");
+ }
}
}
```
I ran this program:
```
import "dart:isolate";
List<Object> data = [];
main() {
RawReceivePort preventClose = new RawReceivePort();
for(int i = 0; i < 10000000; i++) {
data.add(new List<int>()..add(i));
}
for(int i = 0; i < 100000; i++) {
data.add(new Foo(i));
}
}
class Foo {
final int i;
Foo(this.i);
}
```
and requested the toplist by retained memory for class `Foo`.
What before took 121778 ms now takes 81026 ms.
(For smaller numbers in the same test it went from ~10 seconds to ~8 seconds).
Change-Id: I6aee4b0c91af8a9ade116b79e56d1e6cbbee5d09
Reviewed-on: https://dart-review.googlesource.com/70502
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Prior to this fix I get errors like
```
TypeError: Instance of 'b2<bQ>': type 'b2<bQ>' is not a subtype of type 'List<bQ>'
StackTrace:
main.dart.js 1631:3 Object.m
main.dart.js 2001:9 Object.p
[...]
```
Change-Id: I2fc6329c05cb76bff76929aeee1eca3954fbc0a9
Reviewed-on: https://dart-review.googlesource.com/70501
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Until now the expression evaluation implementation was using normal kernel loader
functionality, which registered a new class with the isolate. Then the cid of that
class was set to kIllegalCid.
This caused the direct_subclasses/direct_implementors CHA information to contain a
class with kIllegalCid.
This CL fixes this by ensuring we never register the libraries/classes
created for expression evaluation (which are not even used, they are an artifact
of how the expressions are encoded in kernel).
Issue https://github.com/flutter/flutter/issues/20255
Issue https://github.com/flutter/flutter/issues/20307
Change-Id: Ie6dd76c7ff696cd8adf4f27e9a072274afd90136
Reviewed-on: https://dart-review.googlesource.com/68681
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Having this map file allows for the browser to report source line numbers in case of exception thrown by Observatory code.
Change-Id: Ia47789b89b3a14ca6513143bf9d4cc9c4a8cc1fb
Reviewed-on: https://dart-review.googlesource.com/68847
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Before this CL the test fails because the stacktrace was not as expected
when running in sync async mode.
This CL changes the test so async methods are not executed synchronously
by adding an "await null;" as the first thing in those methods.
An alternative fix would have been to pass --no-sync-async.
Bug: #29158
Change-Id: Idd9bd159610405bbdd479d50d823953a9ad1abde
Reviewed-on: https://dart-review.googlesource.com/63742
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Previously (e71bd048e5) it was assumed that kernels
`script.yield_positions` was for the single function, not for the entire
script. That's not the case.
This resulted in the wrong stack-trace sometimes being produced.
This is technically tested in a service test, though that test also
tests other things and fails before getting to test this.
This CL adds a test that tests only this and fixes the problem.
Cloned from https://dart-review.googlesource.com/c/sdk/+/63741 to
untangle it from two other changes.
Bug: https://github.com/flutter/flutter/issues/17838
Change-Id: I4c24342d63865cb7cbd25c42ba686007bdbde1b1
Reviewed-on: https://dart-review.googlesource.com/66800
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Before this CL the test fails because we land on the "await" when
stepping out of "helper" as "helper" is executed synchronously (i.e.
the call to await (which is translated into a call to an await-helper)
hasn't executed yet so landing on it is "correct").
This CL changes the test so "helper" is not executed synchronously by
adding an "await null;" as the first thing in the test. Once we step out
we thus have already executed the "await" and doesn't land on it.
An alternative fix would have been to pass --no-sync-async.
Change-Id: Iab6e5387960c2ebba10602f5e90630c30172c66e
Reviewed-on: https://dart-review.googlesource.com/63581
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Jens Johansen