- Remove all code that generates the corelib and dart:io library sources into C++ arrays and link them into dart_bootstrap
- Remove the executable dart_bootstrap and all uses of it
- Remove bootstrap_nolib.cc and builtin_nocore.cc
- Remove the Dart 1 code in core lib bootstrap path
Change-Id: Ifd33496204285a08b42fe09e39428e7a92b416b6
Reviewed-on: https://dart-review.googlesource.com/c/77241
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
This way requests to compile won't end prematurely after reading
bytecode if interpreter is enabled.
Change-Id: Ic06cae98ea65bc4656ef491fbd306d34b0e1ef4c
Reviewed-on: https://dart-review.googlesource.com/75628
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Previously we tried to rely on the assumption that all variables would be
boxed - so the machinery for setting correct catch-entry state only
supported tagged values and constants. However this both leads to worse code
and is not entirely correct assumption.
This also:
- renames various confusingly named classes: we move away from talking
about "catch entry state" to "catch entry moves" - because we only
record a subset of moves that needs to be performed and that does
not describe the whole state;
- refactors a bunch of associated code to be more readable and maintainable;
- adds documentation about catch implementation in optimized code
to runtime/docs/compiler;
Fixes https://github.com/flutter/flutter/issues/21685.
Change-Id: I03ae361a1bb7710acbd9f661ae014e663a163c59
Reviewed-on: https://dart-review.googlesource.com/74860
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
After this CL, the interpreter is included by default in the
JIT VM under the flag --enable-interpreter.
Reland with fix to NativeArgument setup in simulator_arm.cc
Change-Id: Ib9b4df6eb4d997dfbe361188b8a127828c1d9c6f
Reviewed-on: https://dart-review.googlesource.com/74003
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Large allocations and direct old space allocations are not signals that the current new space objects will be long lived.
Still perform a scavenge to handle (dead new -> dead old) references even when new space allocation is low, but a non-evacuating scavenge.
Change-Id: I4008fb163c4536abfc7ba42410ec57917a69786a
Reviewed-on: https://dart-review.googlesource.com/72340
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Also move deopt id computation logic into a separate class and add a comment
explaining while deopt ids are incremented by 2.
Change-Id: Ife489be7d10c7198a8e7adf9e97e0c516d78ea55
Reviewed-on: https://dart-review.googlesource.com/72685
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
JitCallSpecializer::VisitInstanceCall has two places where it converts
instance call into a static call. Previously we only made use of
exactness information in one of those places.
On dart2js compiling dart2js this change reduces number of times
we enter Map.putIfAbsent through checked entry point from
1107368 to 8640.
Bug: https://github.com/dart-lang/sdk/issues/31798
Change-Id: Id1665b998ecdf4c4d46cb7605a11bdde2e8c9782
Reviewed-on: https://dart-review.googlesource.com/72220
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Turn it into an isolate specific flag so that Kernel isolate continues
to run from app-jit snapshot without trusting any types.
Change-Id: I627a40025d53c23586da5a207eb096886ca98bc4
Reviewed-on: https://dart-review.googlesource.com/72040
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Test Plan:
Will be tested by following revisions which introduce optimizations that invoke the
new entrypoint.
Change-Id: I56d714bceb92c44a13c46d52457154b82577aa8c
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/67345
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
After this change, ICData map is always unpacked in CompileParsedFunctionHelper::Compile
regardless of the optimizing mode. The unpacked ICData array is passed
both to FlowGraphBuilder and to FlowGraphCompiler.
FlowGraphCompiler::FlowGraphCompiler no longer unpacks ICData array, and
the duplicated code for unpacking of ICData map is replaced with debug asserts.
Change-Id: Ib6864acdb6bcd02fe7acd1cb5bcf70d6c69808af
Reviewed-on: https://dart-review.googlesource.com/67505
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Rationale:
Fixes a bug when JIT compiler sets is_background_optimizable
to false on a function to ensure it is no longer compiled on
the background but on the foreground. Before background
thread would directly put it back on its own queue which,
in some cases, could cause a compilation retry storm.
The new code correctly removes it from the queue so
that, with the higher usage count, the foreground thread
will soon pick it up.
https://github.com/dart-lang/sdk/issues/33664
Change-Id: I6e6041f571c2b32b13911c3b46b8688625d0834e
Reviewed-on: https://dart-review.googlesource.com/66000
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This CL adds experimental --experimental-unsafe-mode-use-at-your-own-risk
VM option which does the following:
* Dart 2 strong mode type and bool checks are omitted.
* VM compiler optimizations which rely on strong mode types are disabled.
Applications which do not fail any strong mode checks at run time
should behave exactly the same in strong and weak modes.
Applications with failing strong mode checks will not see corresponding
errors but VM should not crash.
This option can be used for experiments, or as a temporary remedy for
regressions caused by expensive strong mode type checks.
Change-Id: I042cbccba83c105b61b3e11c659a35c20e0329cd
Reviewed-on: https://dart-review.googlesource.com/65484
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
In certain cases StreamingFlowGraphBuilder was used not for building
flow graph, but as an advanced kernel reader. This CL extracts all such
functionality from StreamingFlowGraphBuilder and revises all such uses.
StreamingFlowGraphBuilder constructors without FlowGraphBuilder are
removed. After this CL StreamingFlowGraphBuilder is only used to build
flow graph, as intended.
Change-Id: I69b08e24d37f8f2f336bee85334af11be1639b24
Reviewed-on: https://dart-review.googlesource.com/64821
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
StreamingScopeBuilder does not build a flow graph, but it was creating
and using StreamingFlowGraphBuilder under the hood (in order to read kernel).
This change makes StreamingScopeBuilder independent of StreamingFlowGraphBuilder
and prepares StreamingScopeBuilder to be moved out of kernel_binary_flowgraph.
Also, several unused classes, fields and parameters are removed.
Change-Id: I40ff983caf0e548529b3c52f44dcb785bd4e9f40
Reviewed-on: https://dart-review.googlesource.com/63305
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
In some cases, bailouts in the bg compiler, e.g. caused by class
finalization, mark functions as unoptimizable, which can significantly
slow down an application.
Instead of doing this, we mark these functions as non-optimizable on the
BG compiler and trigger re-compilations on the main thread.
Change-Id: Ifbb6aa7972818be8fa1313427e38d8b5576053e3
Reviewed-on: https://dart-review.googlesource.com/54886
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Passes bodies are moved into compiler_pass{.cc,.h}.
Invoking a pass is just INVOKE_PASS(Name) now, instead of putting a bunch of
if-s and calls in compiler.cc or precompiler.cc.
We also consolidate ability to print IL and enable-disable passes under a
single flag --compiler-passes, e.g.
--compiler-passes=-Inlining,-CSE disable inlining and CSE passes
--compiler-passes=Inlining+ print IL after Inlining pass and all
subsequent passes
Change-Id: I90ff54b04a54f20099f5bf38dd45b16b8e3c4781
Reviewed-on: https://dart-review.googlesource.com/43968
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Previously, the background compiler was deleted by the thread pool, which could have raced ahead of the mutator clearing its reference. Now it is deleted by the mutator.
Change-Id: Id353a96022f699131ee60fe31156cd0404dfd285
Reviewed-on: https://dart-review.googlesource.com/24342
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
- Remove random build-id.
- Replace build time in embedded version string with commit time.
- Remove timestamps from Observatory tarball.
- Zero-initialize skipped bytes in snapshot streams.
- Fix uninitialized fields in PatchClass, Script and Library.
- Disable (under flag) random identity hashes and concurrent GC.
Bug: https://github.com/dart-lang/sdk/issues/31427
Change-Id: I3e95de679c8372841cd27ca60df78d9b00ffbfe1
Reviewed-on: https://dart-review.googlesource.com/22901
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Coverage uses the value of an execution counter to detect executed functions. However non-positive execution counter does not necessary mean that a function was never executed because we sometimes reset the counter.
Introduce additional bit on a function that is set whenever we reset positive execution counter and use this bit when generating coverage data.
Bug: https://github.com/dart-lang/sdk/issues/31326
Change-Id: I5357109603defad7e7c9415c433203f16bcf88f4
Reviewed-on: https://dart-review.googlesource.com/19760
Commit-Queue: Ryan Macnak <rmacnak@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>
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>
Previously we could hit an assert when for instance "42 ~/ 0"
was being optimized by the background compiler. The reason was
that we assert that we're on the "mutator thread" when allocating
memory (which is done as we're evaluating the code - and we're
trying to evaluate it again because evaluating it gives an error,
and errors aren't cached).
However, to create a test for this it would be better if we could
make it always crash, i.e. use something like
```
--optimization_counter_threshold=5 --no-background-compilation
```
to force an optimization, but still make it crash dispite the
optimization happening in mutator thread (because of
--no-background-compilation).
This CL propagates if we're optimizing to the kernel builder,
and in the constant builder further more asserts that we're not.
Additionally it introduces a test that shows the crash and fixes it.
Change-Id: Ic5412ec8b8a1dbc2ba323f0a02a51103a32fab5c
Reviewed-on: https://dart-review.googlesource.com/11380
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When deciding whether to inline a function that has already been optimized
once, take a look at how many levels of inlining took place when it was
optimized stand-alone. If we don't have that much depth budget left, don't
inline. This is an attempt to avoid the situation where we inline a function
that was already optimized, and then fail to inline important things that are
in the inner loop.
The benchmarking server shows about a 3% improvement on average when running
the DartJS compiler.
This is a reland of https://codereview.chromium.org/2994283002/
Bug
R=vegorov@google.com
Change-Id: Ib2d1f0daad5d68d140bf0266c362dded7a4ea36b
Reviewed-on: https://dart-review.googlesource.com/7706
Commit-Queue: Erik Corry <erikcorry@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When deciding whether to inline a function that has already been optimized
once, take a look at how many levels of inlining took place when it was
optimized stand-alone. If we don't have that much depth budget left, don't
inline. This is an attempt to avoid the situation where we inline a function
that was already optimized, and then fail to inline important things that are
in the inner loop.
The benchmarking server shows about a 3% improvement on average when running
the DartJS compiler
This was reviewed and LGTMed at https://codereview.chromium.org/2994283002
Bug:
Change-Id: Ia731c89f32ac4eacd643965a36dcee35f610c141
Reviewed-on: https://dart-review.googlesource.com/7544
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
asiva