Notes on test changes:
- This revealed runtime failures in some tests in
pkg/front_end/testcases/inference. Since these tests were never
meant to exercise runtime behavior in the first place, I just
changed them so that main() does nothing.
- This revealed runtime failures in some tests in tests/language_2.
These tests began failing because they used "var" for a fields and
then later assigned a value to the field that was incompatible with
the inferred type. It looks like the intent was for these fields to
have type "dynamic", so I changed the tests accordingly.
Change-Id: I0ddb2063427b52b5e4be1884fa333e25be4bf4f3
Reviewed-on: https://dart-review.googlesource.com/16881
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The kernel format has been designed so that one can concatenate several
dill files into one file and then load it. For instance the dart
function BinaryBuilder.readProgram supports this.
Currently a dill file contains one or more programs.
In the VM each of these programs are called either program or subprogram.
Technically a dill "program" isn't necessarily a program at all (e.g. it
could be missing a library).
This naming snafu should probably be cleaned up at some point, but that's
for another CL.
When loading a dill file via BinaryBuilder.readProgram what happens is
this:
- Each program in the dill file ends in 4 bytes that indicates the size
of the program.
- Reading the input from the end one can then read the size, skip back
that amount of bytes, if we have more data (i.e. there's another
program), read another size and so on, and continue until we have
accounted for all bytes in the input.
- We then read each program from the start, and basically overwrite any
library, class, procedure etc. we find.
The first main reference found is the one used though.
(Saying that we overwrite is not completely true, but when the library
is a non-external library that's basically what happens).
This CL introduces (some) support on the C++ side for the same thing.
So far the C++ side could only handle single-program-dills, and trying
to load anything else would probably crash the VM.
The support added is this:
- Assume the SDK (i.e. vm_platform.dill) is not a concatenated file
(error out if it is).
- For user provided input, loop over each contained program one-by-one,
for each individual one behave as normal.
- The way LibraryLoad is implemented (i.e. it skips if the library is
already loaded) this means that it currently would behave differently
than the dart version (i.e. the first one is used, not the last one).
For now it is assumed that that's not a problem.
- There is a possibly snafu if the same script is included several times.
This could probably mostly be remedied by not creating scripts up front,
but only as needed. By the "keep only one" (and fixing the above point,
probably by simply loading in the opposite order, i.e. last program
in the binary first) the (theoretical) problem would probably do away.
Note that we will have separate string tables, canonical name tables etc
per "sub program" and that there might be some duplication.
The implementation was tested as indicated below, but introduces no tests.
$ cat test_lib1.dart
import "test_lib2.dart" as lib2;
String lib1field = "lib #1 field!!";
main() {
foo();
lib2.foo();
print("From lib2: ${lib2.lib2field}");
}
foo() {
print("Hello, Foo, from test_lib1!");
var x = 42;
print(x);
}
$ cat test_lib2.dart
String lib2field = "Lib #2 field!!!!";
foo() {
print("Hello, Foo, from test_lib2!");
var y = 34;
print(y);
}
$ out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart --packages=.packages --platform=out/ReleaseX64/vm_platform.dill test_lib1.dart
$ ls -lha test_lib1.dart.dill
[...] 4.2M Oct 26 14:42 test_lib1.dart.dill
$ dart pkg/kernel/bin/split.dart test_lib1.dart.dill
Wrote test_lib1.dart.dill.part1.dill
Wrote test_lib1.dart.dill.part2.dill
$ ls -lha test_lib1.dart.dill.part{1,2}.dill
[...] 811 Oct 26 14:42 test_lib1.dart.dill.part1.dill
[...] 582 Oct 26 14:42 test_lib1.dart.dill.part2.dill
$ cat test_lib1.dart.dill.part1.dill test_lib1.dart.dill.part2.dill > test_lib1.dart.dill.concat.dill
$ ls -lha test_lib1.dart.dill.concat.dill
[...] 1.4K Oct 26 14:44 test_lib1.dart.dill.concat.dill
$ out/ReleaseX64/dart --kernel-binaries=out/ReleaseX64 --packages=.packages test_lib1.dart.dill.concat.dill
Hello, Foo, from test_lib1!
42
Hello, Foo, from test_lib2!
34
From lib2: Lib #2 field!!!!
Change-Id: I233a033aa3042b202dd4708908a5be3089474588
Reviewed-on: https://dart-review.googlesource.com/16820
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Improves the space overhead of compaction from O(size of live objects) to O(number of live objects).
Future work includes:
- a smaller, faster representation the forwarding table via a bitmap of used allocation units
- sorting class sizes off-heap to allow sliding classes
- running forwarding in parallel
Removes unnecessary sweep from evacuating compactor.
Change-Id: If0991bfb75573201c6e8feed142ca0cc69fccab4
Bug: https://github.com/dart-lang/sdk/issues/30978
Reviewed-on: https://dart-review.googlesource.com/15988
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Erik Corry <erikcorry@google.com>
CloneContext is implemented as a runtime call so it is considerably slower
than AllocateContext which leads to performance issues in loops that capture
iteration variables in for loops.
Lowering CloneContext into AllocateUninitializedContext and a sequence of
explicit load&store instructions both improves the performance by avoiding
the runtime call and also makes CloneContext semantics exposed to store-load
forwarding and allocation sinking.
PutIfAbsent benchmark from issue #31113 is improved by 5x, while
ForInGeneratedLoop benchmark is improved by 8x.
Bug: https://github.com/dart-lang/sdk/issues/31113
Change-Id: I03fdede75f1a85fda92487aa8f9307ce06f23903
Reviewed-on: https://dart-review.googlesource.com/16280
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Currently, the Kernel FE doesn't set up parent pointers correctly for
signature function types. This prevents type parameters on generic
function types from being finalized correctly. In addition, finalization
of generic interface types within a generic function type can crash if they
reference not-yet-finalized type parameters of the enclosing function type.
This review solves both issues. Several failing tests pass again, although
more thorough testing is blocked on Github issue #31213 (nested generic function
types crashing in Fasta).
Bug:
Change-Id: Ib5ee6b2566492e3fd6688fe5a6b6976692562ea1
Reviewed-on: https://dart-review.googlesource.com/16360
Reviewed-by: Régis Crelier <regis@google.com>
This reverts commit eebbac4d78.
Reason for revert: Crash on ASAN bots
Original change's description:
> [vm] Tighten stack overflow check in the parser.
>
> A recent change increased the accuracy of the stack limit used in the stack overflow check. This allowed the parser to complete some example programs that previously tripped the limit, but the flow graph builder or optimizer (depending on mode) then experienced the overflow. Rather than sprinkle checks throughout the compiler pipeline, we now flag an error in the parser based on the amount of nesting instead of amount of call stack used.
>
> Bug: https://github.com/dart-lang/sdk/issues/31158
> Change-Id: I794e484d736e61499fe6812cf25185ce097bcdd8
> Reviewed-on: https://dart-review.googlesource.com/15651
> Reviewed-by: Zach Anderson <zra@google.com>
TBR=rmacnak@google.com,zra@google.com
Change-Id: I232d929b24c54191d6688530c6f4c59dcccb5890
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://github.com/dart-lang/sdk/issues/31158
Reviewed-on: https://dart-review.googlesource.com/16400
Reviewed-by: Ryan Macnak <rmacnak@google.com>
A recent change increased the accuracy of the stack limit used in the stack overflow check. This allowed the parser to complete some example programs that previously tripped the limit, but the flow graph builder or optimizer (depending on mode) then experienced the overflow. Rather than sprinkle checks throughout the compiler pipeline, we now flag an error in the parser based on the amount of nesting instead of amount of call stack used.
Bug: https://github.com/dart-lang/sdk/issues/31158
Change-Id: I794e484d736e61499fe6812cf25185ce097bcdd8
Reviewed-on: https://dart-review.googlesource.com/15651
Reviewed-by: Zach Anderson <zra@google.com>
Currently, we have some tests that run with reified generic functions ON and
some with it OFF. However, this causes inconsistencies when running the Kernel
FE from snapshot in the VM, since the VM requires that the flag be consistent
with the snapshot. Our solution is to turn the reified generic functions flag
into a per-isolate flag, which is always disabled in the Kernel FE's isolate.
Bug:
Change-Id: Ia91e9f0ff5fc059edf4bdbd79ef14abb288b4a49
Reviewed-on: https://dart-review.googlesource.com/16020
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Includes the following changes:
- Disable type checking in the service isolate when strong mode is
turned on. We don't yet have strong mode clean vmservice Kernel
binary available (Issue #31203);
- Introduce new Dart VM API to allow creating List<T> (T in {String, int}).
Current API only allows to create List<dynamic> and in strong mode
List<dynamic> is not assignable to List<T>. For now we limit this API to
a fixed number of core types for performance considerations (type
arguments can be canonicalized and cache ahead of time). We will
extend the API allowing creation of arbitrary List<T> if we will
discover the need for it later;
- Use this new API to fix CreateRuntimeOptions to create List<String>
and not List<dynamic>;
- Likewise fix OneByteString_splitWithCharCode to return List<String>
and not List<dynamic>;
Additionally this CL refactors how getters and setters are created
in object_store.h removing 500 lines of largely boilerplate code.
Bug: https://github.com/dart-lang/sdk/issues/31052
Change-Id: I3fdcd2d54ff3f307db0913c67a7c2f009ea9d7a7
Reviewed-on: https://dart-review.googlesource.com/15884
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
For 1-byte strings we don't need the full power of UTF-8 conversion with
support for 3 and 4-byte sequences and reassembly of UTF-16 surrogate pairs.
This optimization was originally intended to improve the reverse-complement
benchmark. It also seems to have a positive effect (ca. 1% on average) on
dart2js.
After implementing this it doesn't seem worth having a special case in
ToCString for ASCII strings. That special case would allocate the string twice
for all Latin1 strings, which feels unfortunate.
R=vegorov@google.com
Bug:
Change-Id: If852f3ecb4e06118da8357cfa2c843ad0df0edb9
Reviewed-on: https://dart-review.googlesource.com/8920
Commit-Queue: Erik Corry <erikcorry@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Change abefb7b432 introduced a typing issue
instead of fixing it: _SyncIterator<T>._current was actually used to return
either a value of type T (for yield) or value of type Iterable<T> (for yield*)
from the move callback.
This change refactors implementation of _SyncIterator in such a way that
_current is only used to return value for yield and a separate field
_yieldEachIterable is used to return Iterable<T> for yield*.
Change-Id: I3e3c832bbc8986d6976ddbb0856a1b5a127d845b
Reviewed-on: https://dart-review.googlesource.com/15542
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL improves performance of allocation statistic counters on ARM
by removing duplicated loads and increasing distance between dependent
loads. These statistic counters are part of allocator fast path in a
non-product mode.
This change improves performance of gestures/velocity_tracker_bench
Flutter micro-benchmark in 'flutter run --profile' mode:
Before: 3352 µs
After: 3156 µs (-5.8%)
(minimum of 5 runs)
Change-Id: Ic7998318d9ca3e7997379d0054faaf5b0b569bb6
Reviewed-on: https://dart-review.googlesource.com/15640
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
To pass a CWD to a child through launchpad, simply set
the PWD environment variable, and the child will open
their CWD relative to their root handle when they initialize.
Change-Id: I24cd01c05e705c5a0ec2dfbaae4dbe8de42d7ed4
Reviewed-on: https://dart-review.googlesource.com/15421
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
When message snapshot writer serializes an object it references
object's class as a tuple [library-url, class-name]. However it
does not scrub these names (String::ScrubName can cause an
allocation and subsequently a GC which means it can't be used
when writing snapshot). As a result of this private names
arrive mangled to the receiving isolate, which would fail to
look these names up if its private library keys are different.
This patch fixes sporadic failures that can be caused by this.
Note: even if two isolates start from the very same main URI
libraries in those isolates might end up with different private
keys because private key consists of library-sequence-number
and a URL hash. URL hashes are guaranteed to be stable but
library-sequence-numbers might get out of sync due to
asynchronous loading.
Fixes https://github.com/dart-lang/sdk/issues/31148
Change-Id: Iccb10a473a1e77e00f4bda54cbff8579d6373bc1
Reviewed-on: https://dart-review.googlesource.com/15081
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
This declaration lets us add the dart command line program to the Fuchsia
system image.
Change-Id: I5a1049a47693bd0c0a1287a652758ae7047a4f06
Reviewed-on: https://dart-review.googlesource.com/15008
Reviewed-by: Zach Anderson <zra@google.com>
Parameterize hash map entries and iterators with appropriate type arguments.
Cleanup code that was declaring local variables with unnecessary explicit types,
while at the same time dropping relevant type arguments (e.g. List instead of
List<_HashMapEntry<K, V>>).
Bug: https://github.com/dart-lang/sdk/issues/31052
Change-Id: I420e84e9ba549d7a9713970c85dbccc19d26761f
Reviewed-on: https://dart-review.googlesource.com/15121
Reviewed-by: Erik Corry <erikcorry@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
NativeArguments don't allow you to access type arguments, but calling
conventions are setup in such a way that nothing else needs to be
changed.
This is needed because we changed
List makeListFixedLength(List growableList)
native "Internal_makeListFixedLength";
to
List<T> makeListFixedLength<T>(List<T> growableList)
native "Internal_makeListFixedLength";
Bug:
Change-Id: I2f8755f25c488a422a60f3efce2541de7cbeae0e
Reviewed-on: https://dart-review.googlesource.com/15080
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Samir Jindel