On the otherwise path it was producing a block that ended with a call. Such IR
is invalid because blocks can only end with control flow instructions, like
Branch, Goto, Return or Throw.
Bug:
Change-Id: I67971fba00c01f1e063ac584abfa6aec2ea376d9
Reviewed-on: https://dart-review.googlesource.com/19004
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
With the current block size, this reduces space for forwarding information from two words per moved object to two words per (kObjectAlignment * kBitsPerWord) bytes of heap (1.6% on 64-bit, 3.1% on 32-bit).
dart2js compiling dart2js:
Compactor/Sweeper Runtime Max RSS
Sliding (binary search table) 105 s 1.085 GB
Sliding (bitvector) 57.8 s 998.566 MB
Evacuating 66.2 s 1.714 GB
Concurrent sweep 53.8 s 1.183 GB
Blocking sweep 55.0 s 1.181 GB
Bug: https://github.com/dart-lang/sdk/issues/30978
Change-Id: Ia6eec4f0162c3959154c5155df24cc06694ecac7
Reviewed-on: https://dart-review.googlesource.com/17721
Reviewed-by: Erik Corry <erikcorry@google.com>
The purpose of this refactoring is to provide a convenient way to
write JSON independently of VM service, which is excluded in PRODUCT
build mode.
Change-Id: I55700d9ead6ef9269a98714d8178f1edb35435cb
Reviewed-on: https://dart-review.googlesource.com/18502
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
It appears like the manual flow graph building code for
MethodRecognizer::kObjectRuntimeType is wrong and was exposed by
enabling it recently.
Change-Id: Ia4be8c4bc7c3342e0cdf1cb8b270dc48b5f2fde4
Reviewed-on: https://dart-review.googlesource.com/17920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Now that we do eager rehashing of linked hashmaps we no longer have the
index field be `null` (which in the past signaled we needed rehashing).
This means we can teach the optimizer that loads from the index fied
always result in kTypedDataUint32ArrayCid.
Change-Id: Ic012881c12b2310a6337696521fa1355afd4069f
Reviewed-on: https://dart-review.googlesource.com/17447
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Previously we would sometimes build specifically hand-crafted flow graph
code for recognized methods and sometimes let the normal flow graph
builder do it (depending on whether inlining was triggered via
[CallSiteInliner] or [CallSpecializer]).
This CL makes us use the hand-crafted flow graph building for recognized
methods in both cases.
Change-Id: I58405b16adca810fd7ccff32027b9d4a13858976
Reviewed-on: https://dart-review.googlesource.com/17445
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This change brings down core snapshot size by ~750KB, and brings
down app-jit snapshot size of simple "Hello, World" dart script by
~650KB. The bot cycle times will also come down by around ~20%.
Change-Id: I2a01c98bedc7ebfa2a653983995486a71504daf3
Reviewed-on: https://dart-review.googlesource.com/16323
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Remove parsing support for 'super' that was meant to declare lower bounds of
function type parameters, since this feature did not make it into the spec.
Change-Id: I4087d0e108c5984437083a05a065fe785888d2f7
Reviewed-on: https://dart-review.googlesource.com/17360
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This is a baby-step towards building an SDK targeting the host arch
during a cross-build. This will require a similar update to the use
of dart_config in the Flutter engine at //flutter/lib/io/BUILD.gn:19.
Change-Id: I8b871cceb53038cab8407264664c5ce545e6e010
Reviewed-on: https://dart-review.googlesource.com/17523
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This improves
* JIT performance by around 14%
* precompiled performance by around 2%
on a simple map microbenchmark.
Change-Id: I623e2a715a709f89f2514ae30fbb504ee2e31661
Reviewed-on: https://dart-review.googlesource.com/17165
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This allows the normal VM metadata lookup code to find metadata attached
to members which come from mixed-in classes.
This allows e.g. putting a @AlwaysInline / @NeverInline annotation on
methods of mixin classes.
Change-Id: I70639dc78fc5bab98ac7cee107c2042f84d07888
Reviewed-on: https://dart-review.googlesource.com/17164
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@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>
Alexander Markov