Comments

[vm/kernel/bytecode] Do not copy captured top-level parameters in closures
Receiver and factory type arguments are implicit parameters which are
copied from original stack locations to a context if captured (along
with explicit parameters).
However, they were copied not only in top-level members, but also in
closures. So sometimes context was corrupted with unrelated values
taken from the stack (as closures do not receive these parameters
on the stack).
This CL removes incorrect copying of implicit parameters in closures.
Change-Id: I8d7d3992595f761f4ab7a1c8d16e0fc823fae22a
Reviewed-on: https://dart-review.googlesource.com/71101
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>

Comments

[VM] Fix SEGV in inliner: Reading the metadata of a function can fail
In this particular case, the kernel-isolate, while executing 'main', was
killed during `Dart_Cleanup()`. The kill is performed via an OOB message
which will trigger an exception to propagate up. This will cause the
`Library::GetMetadata()` function to return an error object.
Change-Id: Ie400e50473972875eb338a688bb77c23a562c936
Reviewed-on: https://dart-review.googlesource.com/71163
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>

Comments

Require super initializer to be at the end of the initializer list.
Drops code to handle special evaluation order rules for super
initializer before the end.
Initializer check code now also recovers from initializer errors.
Fixes https://github.com/dart-lang/sdk/issues/33101
Change-Id: I1024853bfd3acfef42630bdc2fc47782746b07c0
Reviewed-on: https://dart-review.googlesource.com/68060
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>

Comments

Signal a compile-time error when a type variable name conflicts with a setter name.
Specification disallow name conflicts between
- type variables and class names
- type variables and getter names
- type variables and member names
Although not present in current specification, the language team confirms that
it is also supposed to be a compile-time error if there is conflict with a setter.
Closes https://github.com/dart-lang/sdk/issues/33827
Bug:
Change-Id: Ia25bc91c3287f93ae43faae121a1f9d81b179c6b
Reviewed-on: https://dart-review.googlesource.com/70500
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>

[vm] Add support for a new source file format kernel file lists.

Comments

[vm] Add support for a new source file format kernel file lists.
Given a source file that starts with '#@dill' on a new line, then if the rest of the lines are full paths to the kernel dill files, all kernel dill files will be loaded and executed as single program.
So, for example, given `mytest.dillref` with following content:
```
/projects/mytest/build/bin/main.vm.dill
/projects/mytest/build/packages/mytest/lib.vm.dill
```
invocation of `dart mytest.dillref` will result in loading two dill files and starting combined app.
Bug: dartbug.com/33952
Change-Id: I22a99ec9a018da1bc984bc0d716af94bc10e20d6
Add few tests
Change-Id: I22a99ec9a018da1bc984bc0d716af94bc10e20d6
Reviewed-on: https://dart-review.googlesource.com/67460
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>

[vm/kernel/bytecode] Share contexts between scopes in bytecode

Comments

[vm/kernel/bytecode] Share contexts between scopes in bytecode
This optimization reduces number of context allocations and decreases
number of context levels, making access to captured variables more
efficient.
This change reduces number of context levels in synthetic bodies of
sync* methods to 1. This is important for correctness because
_SyncIterable::iterator clones unerlying sync* closure to create a new
Iterator using _Closure._clone(), and _Closure._clone() clones only
1 level of context.
Fixes language_2/syncstar_yield_test in bytecode mode.
Change-Id: I7a783702b024a7454253f7f4423ec4b2e08ef61f
Reviewed-on: https://dart-review.googlesource.com/70984
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>

Comments

Change code ranges for fields/variables.
We used to set the code range of the whole FieldDeclaration for each
individual VariableDeclaration even when there are multiple of them.
Now the first VariableDeclaration will use code range that starts at
the beginning of the FieldDeclaration, and ends at the end of its
initializer. The subsequent variables (if any) will start of the
start of their names. So, each variable will get unique code range.
R=brianwilkerson@google.com
Change-Id: I0a93bdad2a17454fd5b343b395c72440c86b421d
Reviewed-on: https://dart-review.googlesource.com/70981
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>

[vm, gc] Make bypass_safepoints on helper threads sticky.

Comments

[vm, gc] Make bypass_safepoints on helper threads sticky.
Allows concurrent marking and sweeping to continue during safepoints. However, the sweeper still cannot make much progress during a scavenge due to the scavenger holding the freelist lock.
Bug: https://github.com/dart-lang/sdk/issues/34002
Change-Id: I84f3f48feb81e8eeb67c418e918a6e12aa3178c9
Reviewed-on: https://dart-review.googlesource.com/70900
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>

Squelch some false warnings for disallowed uses of void

Comments

Squelch some false warnings for disallowed uses of void
The rules for void are changed to allow uses of void where we
previously had a warning, such as the case of assignment to a
variable of type void or passing as a parameter of type void.
Change-Id: I1c1513b0000fa1c8eedbe2645fab503b28024fa3
Reviewed-on: https://dart-review.googlesource.com/70265
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>

Analyzer: replaceComponent: Add small to big instead of the other way around

Comments

Analyzer: replaceComponent: Add small to big instead of the other way around
Instead of adding a big (old) map to a small (new) map and clearing the old
one, add the new entries the old map and let GC take the new map.
--use-cfe analysis-server-cold goes from ~48 to ~43 on my machine.
Change-Id: Ia0ff7bc4cafcea8e11fd9eb4eebd0cfec504b96f
Reviewed-on: https://dart-review.googlesource.com/70643
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>

Changed files

pkg/analyzer/lib/src/dart/analysis/kernel_metadata.dart

Fix analyzer/FE integration of invalid assignments to classes.

Comments

Fix analyzer/FE integration of invalid assignments to classes.
To ensure that the resolution of the class name is communicated to the
analyzer, we take advantage of SyntheticExpressionJudgment.original,
which allows us to ensure that type inference is performed on a
synthetic read of the class name expression. This causes the
appropriate information to be communicated to the analyzer, and then
at runtime the value produced by the synthetic read is discarded.
Fixes 15 language_2 tests with [ $compiler == dart2analyzer && $fasta ].
Change-Id: I02ad23acbb64c297129f59ff56171399bf067c33
Reviewed-on: https://dart-review.googlesource.com/70780
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>

Fix status file for super_call4_test/01

Comments

Fix status file for super_call4_test/01
We were attempting to "override" a failing test for the analyzer by
putting a "pass" annotation in a more specific section of the status
file. But that doesn't have the intended effect--it just means that
when the test is run for the analyzer, either a pass or a fail result
is accepted.
Change-Id: Iccd7e68c746e7989840c6d0e6ee16bd4f0677e2d
Reviewed-on: https://dart-review.googlesource.com/70163
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>

[vm] Fix a bug in the field exactness tracking state machine.

Comments

[vm] Fix a bug in the field exactness tracking state machine.
We were returning without initializing the state of the static
type exactness.
Change-Id: I447597cbe383470297a7f660addb60d0031cabba
Reviewed-on: https://dart-review.googlesource.com/70661
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>

Changed files

runtime/vm/object.cc

[vm] Use multiple entrypoints to remove unnecessary checks on calls against "this".

[vm] Fix few issues with field exactness tracking.

Comments

[vm] Fix few issues with field exactness tracking.
- Don't add dependency on fields that are either unitialized or already marked
as non guarded (guarded cid is kIllegalCid in the first case and kDynamicCid
in the second case).
- Exit early from FieldStore if guarded_cid is kDynamicCid (or we are storing
null into a nullable field).
- Don't track exactness of fields which have function type type.
Also move logic for starting to track fields into class_finalizer because we
need resolved field types to make our decisions.
Change-Id: I164b42abe3108a70b0769f4c78d92459b4e78883
Reviewed-on: https://dart-review.googlesource.com/70620
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>

[vm/intrinsics] Introduce dart:_internal.uncheckedCast.

Comments

[vm/intrinsics] Introduce dart:_internal.uncheckedCast.
This function can be used to avoid checked down casts in the parts
of the code where we know by construction that the type of the
value matches expectations.
Use it to avoid down-cast in the _LinkedHashMap.operator[].
Bug: https://github.com/dart-lang/sdk/issues/31798
Change-Id: I80949bfb84dde7716fc23aeba311931970ce16aa
Reviewed-on: https://dart-review.googlesource.com/70511
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>

Speedup calculation of toplist by retained memory in Observatory

Comments

Speedup calculation of toplist by retained memory in Observatory
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>

[vm] Deep clone context when cloning closure

Comments

[vm] Deep clone context when cloning closure
_SyncIterable::iterator clones unerlying sync* closure to create a new
Iterator using _Closure._clone(). _Closure._clone() was cloning only
1 level of context, relying on a particular context structure.
In bytecode, contexts are allocated in a different way, so sync*
functions could have more then 1 level of contexts. In such case,
parent contexts were not cloned in _Closure._clone() and were shared
between Iterator instances.
This CL adds deep cloning of contexts into _Closure._clone() native method
in order to handle arbitrary number of levels of contexts in a closure.
Fixes language_2/syncstar_yield_test test in bytecode mode.
Change-Id: Ic5ced4c32fc2e21726db76608cd3a7db7e553472
Reviewed-on: https://dart-review.googlesource.com/70600
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>