Incrementing the usage counter of the calling function (icdata owner) during
an instance call does not seem the correct thing to do.
In kernel bytecode, the counter is incremented as part of executing the
CheckStack instruction occuring at the beginning of each function.
In Dart bytecode, the counter is incremented as part of executing the
HotCheck instruction.
Change-Id: I2e4eebc9ae682520b93518e76e1c6856d5d9bb78
Reviewed-on: https://dart-review.googlesource.com/c/86001
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Régis Crelier <regis@google.com>
This is a major revamp of bytecode metadata format. Now bytecode has
its own serialization mechanisms.
This CL adds 'bytecode component' metadata, which contains bytecode
object table and string table. All references from bytecode (constant
pools) to libraries, classes, members, types and strings now have a new
format. References to frequently used objects are represented as indices
in object table, while rarely used objects are written inline.
This allows VM to cache frequently used objects while reading bytecode.
Representation of strings is aligned with VM - string characters are
stored in separate pools of one-byte and two-byte strings. This allows
VM to avoid UTF-8 decoding and extra copying.
Closure declarations are now explicit. Type parameters no longer require
enslosing scopes when reading/writing them.
Benchmarks:
GenKernelKernelReadAllBytecode (Intel Core i5) +29.84%
GenKernelKernelReadAllBytecode (Intel Xeon) +28.74%
Change-Id: I4b80009733a8f8c038264af74f97c4e094b9e311
Reviewed-on: https://dart-review.googlesource.com/c/85469
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
This change extends/fixes the exiting "pattern recognition" which tries
to recognize the pattern
v2 <- LoadClassIdInstr(v1)
BranchIf v2 == IntegerConstant(cid)
Furthermore we start inlining the recognized `ClassID.getID` method very
early in the pipeline. This allows the VM to recognize the above
pattern and insert redefinitions before the actual inlining pass.
Furthermore we special-case two very hot methods in utf8 decoding by
manually having two loops, one of which is guarded by a class-id check
against the _Uint8ArrayView class, which is most common. (In the future
we would like to unify the typed data layouts so we no longer need to
use `ClassId.getID`, thereby also allowing non core library code to use
this).
This improves dart-aot by
* 31%+ for a protobuf decoding benchmark we care about
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: I7181bbf096aabe303634fd3b2bff9cc96d69719c
Reviewed-on: https://dart-review.googlesource.com/c/85443
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
After recent changes to pragmas, TFA devirtualizes more calls, which has
regressed a Prime
This gets rid of the 5% regression in PrimeNumber/PrimeNumberTyped in
dart-aot (which 0ef66e0f5 introduced). Furthermore it improves MD5/SHA
by double digits percent.
Change-Id: Ia4d1fb62512495dec7111efc53c4d7a4de5ef3af
Reviewed-on: https://dart-review.googlesource.com/c/85398
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reverts commit d7cf6959bb.
Reason for revert: This causes crashes on the vm-obfuscate builder at https://ci.chromium.org/p/dart/builders/luci.dart.ci.sandbox/vm-kernel-precomp-obfuscate-linux-release-x64
like
FAILED: dartkp-dart_precompiled release_x64 corelib_2/linked_hash_map_test
Expected: Pass
Actual: Crash
Unexpected compile error.
--- Command "vm_compile_to_kernel" (took 11.000189s):
DART_CONFIGURATION=ReleaseX64 /b/s/w/ir/cache/builder/sdk/pkg/vm/tool/gen_kernel --aot --platform=out/ReleaseX64/vm_platform_strong.dill -o /b/s/w/ir/cache/builder/sdk/out/ReleaseX64/generated_compilations/dartkp/tests_corelib_2_linked_hash_map_test/out.dill /b/s/w/ir/cache/builder/sdk/tests/corelib_2/linked_hash_map_test.dart --packages=/b/s/w/ir/cache/builder/sdk/.packages -Ddart.developer.causal_async_stacks=true
exit code:
0
--- Command "precompiler" (took 583ms):
DART_CONFIGURATION=ReleaseX64 out/ReleaseX64/gen_snapshot --snapshot-kind=app-aot-assembly --assembly=/b/s/w/ir/cache/builder/sdk/out/ReleaseX64/generated_compilations/dartkp/tests_corelib_2_linked_hash_map_test/out.S --obfuscate --sync-async --ignore-unrecognized-flags --packages=/b/s/w/ir/cache/builder/sdk/.packages /b/s/w/ir/cache/builder/sdk/out/ReleaseX64/generated_compilations/dartkp/tests_corelib_2_linked_hash_map_test/out.dill
exit code:
-6
stderr:
Warning: This VM has been configured to obfuscate symbol information which violates the Dart standard.
See dartbug.com/30524 for more information.
===== CRASH =====
version=2.2.0-edge.83712405657ff736033380cb24b0bd5a62fc3692 (Tue Nov 27 16:56:07 2018 +0000) on "linux_x64"
si_signo=Segmentation fault(11), si_code=1, si_addr=0xd1400050e5f
Dumping native stack trace for thread 2b71
[0x000056001fc426c7] Unknown symbol
[0x000056001fc426c7] Unknown symbol
[0x000056001fe5763d] Unknown symbol
[0x000056001fe4c99c] Unknown symbol
[0x000056001fe6166a] Unknown symbol
[0x000056001fe59c0c] Unknown symbol
Original change's description:
> [VM] Inline ClassID.getID() eagerly, extend pattern matching logic to recognize it, use it to special case ascii decoding
>
> This change extends/fixes the exiting "pattern recognition" which tries
> to recognize the pattern
>
> v2 <- LoadClassIdInstr(v1)
> BranchIf v2 == IntegerConstant(cid)
>
> Furthermore we start inlining the recognized `ClassID.getID` method very
> early in the pipeline. This allows the VM to recognize the above
> pattern and insert redefinitions before the actual inlining pass.
>
> Furthermore we special-case two very hot methods in utf8 decoding by
> manually having two loops, one of which is guarded by a class-id check
> against the _Uint8ArrayView class, which is most common. (In the future
> we would like to unify the typed data layouts so we no longer need to
> use `ClassId.getID`, thereby also allowing non core library code to use
> this).
>
> This improves dart-aot by
> * 31%+ for a protobuf decoding benchmark we care about
>
>
> Issue https://github.com/dart-lang/sdk/issues/31954
>
> Change-Id: Ia567b92b7e76ff28eda1726deaafda32732ed8f5
> Reviewed-on: https://dart-review.googlesource.com/c/85281
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
> Reviewed-by: Jenny Messerly <jmesserly@google.com>
> Commit-Queue: Martin Kustermann <kustermann@google.com>
TBR=vegorov@google.com,kustermann@google.com,jmesserly@google.com,johnniwinther@google.com,sra@google.com
Change-Id: I912b0768c32cbb00297ce48db29dbdbea44c14fa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/85441
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: William Hesse <whesse@google.com>
This change extends/fixes the exiting "pattern recognition" which tries
to recognize the pattern
v2 <- LoadClassIdInstr(v1)
BranchIf v2 == IntegerConstant(cid)
Furthermore we start inlining the recognized `ClassID.getID` method very
early in the pipeline. This allows the VM to recognize the above
pattern and insert redefinitions before the actual inlining pass.
Furthermore we special-case two very hot methods in utf8 decoding by
manually having two loops, one of which is guarded by a class-id check
against the _Uint8ArrayView class, which is most common. (In the future
we would like to unify the typed data layouts so we no longer need to
use `ClassId.getID`, thereby also allowing non core library code to use
this).
This improves dart-aot by
* 31%+ for a protobuf decoding benchmark we care about
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: Ia567b92b7e76ff28eda1726deaafda32732ed8f5
Reviewed-on: https://dart-review.googlesource.com/c/85281
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Rationale:
Replacing the simple induction analysis in the range analyzer
with the new framework for finding induction variables removes
a lot of code and even saves some memory in the IR (for phis).
Note that this is only the first phase, i.e. using the new
framework for the same behavior in the range analyzer. In the
second phase, the new framework will be fully exploited to
compute more accurate ranges in many more cases.
Change-Id: Iae5bd5a155ef8592558b5bdb2388c5aa9da64e59
Reviewed-on: https://dart-review.googlesource.com/c/84500
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Aart Bik <ajcbik@google.com>
If we inline something inside a loop which might throw, the throwing blocks
are currently spliced in the middle of the loop. This CL moves those blocks
to the very end.
This improves a number of typed data benchmarks in dart-aot mode by 5-10%.
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: I5dc86291240d8dac61798ff873ffa7205edc0007
Reviewed-on: https://dart-review.googlesource.com/c/85263
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Makes public some include paths needed for the dart_runner to depend on
dart_io.
Also updates some dart:io implementations to give and OSError
instead of crashing when something is unimplemented.
Change-Id: I862fc7cc43f56e74de791ecc021b88238b54a8e5
Reviewed-on: https://dart-review.googlesource.com/c/84920
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
A field/function annotated with this pragma must be guaranteed to not
return `null` at runtime.
Make use of this non-nullable annotation in the VM's type propagator.
Annotates the "_TypedListView._typedData" field to ensure the VM knows it
returns a non-nullable _TypedListView.
Furthermore annotates methods on the integer implementation. Those particular
methods are recognized methods with a "dynamic" return type. This caused
the type propagator to use CompileType::Dynamic() as result type. Since a
previous CL started to only utilize the annotated type if it is better than
"dynamic" more integer operations got handled in-line, though with null-checks.
Annotating those methods to return non-null improves the in-line handling of
integer operations.
This improves dart-aot
On arm7hf:
SHA256: +5%, SHA: +6%, JsonObjectRoundTrip: +7%, ...
On arm8:
SHA1: +28%, MD5: +25%, SHA256: +15%, TypedData.Int16ListViewBench: +18.5%, StringInterpolation: +18%, ...
Issue https://github.com/dart-lang/sdk/issues/31954
Issue https://github.com/dart-lang/sdk/issues/35154
Change-Id: Ia4263a37241a36c9dc35e8a48893297effa6f4b2
Reviewed-on: https://dart-review.googlesource.com/c/84421
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Until now a typed data view was first constructed and then afterwards the
constructor body validated that the offsetInBytes/length are non-null
and in range.
This CL moves the range check to the call sites of the constructor,
thereby guarenteeing that we will never initialize the
_TypedListView.{offsetInBytes,length} fields with non-_Smi values. (The
views are constructed only within the "dart:typed_data" library. Neither the
embedder nor the runtime construct them.)
Further more this CL removes the redundant _defaultIfNull() call, since
the call sites already handled the `length == null` case.
This CL also starts annotating _TypedListView.{offsetInBytes,length}
with @pragma("vm:exact-result-type", "dart:core#_Smi") to ensure any
[LoadFieldInstr] will have the right type attached, thereby avoiding any
null-checks and mint-handling.
This improves dart-aot
On arm7hf:
MD5: +38%, SHA256: +87%, SHA1: +89% (plus various typed data microbenchmarks)
JsonParseDefaultReviver/StringBuffer/StringIdiomatic/JsonParseCustomReviver: -5-8% (probably due to not inlining static calls, will find out)
On arm8:
MD5: +6.5%, SHA256: +12%, SHA1: 3.6%, JsonUtf8RoundTrip: 8% (plus various typed data microbenchmarks)
DeltaBlue: -6.7% (probably due to not inlining static calls, will find out)
Issue https://github.com/dart-lang/sdk/issues/35154
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: I37c822e6879f5a2d17fd9650a68cf2eee4326b01
Reviewed-on: https://dart-review.googlesource.com/c/84241
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When @pragma('vm:exact-result-type') was introduced, the return types
specified in the recognized method lists were **duplicated** (they were
in the method recognizer macro lists as well as in the dart source code).
This CL removes this duplication by removing the result types from the
method recognizer lists.
Change-Id: I2082110cf77fc3b97d1a541cb153abb8c17990d0
Reviewed-on: https://dart-review.googlesource.com/c/84220
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Currently the @pramga('vm:exact-result-type') annotation only works if
the function is a recognized method. This change changes that to make
the VM just look if a function has the annotation (no matter if it's
also in the list of recognized methods or not).
Furthermore this CL lets the type propgagator use
@pragma('vm:exact-result-type') annotations to narrow the [CompileType]
set on [LoadFieldInstr]s.
Since the @pragma is a general feature, this CL moves the
`Function::FindPragma()` to `Library::FindPragma` (which is where any
other metadata lookup happens). We also let the `FindPragma` accept any
of Class/Function/Field objects.
Furthermore the `FindPragma()` function is fixed to handle the case
when the evaluation of the metadata results in an error.
In this case we simply claim to not have found a pragma annotation.
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: If03f566e334cd53549985823ee3dd6b5e9672969
Reviewed-on: https://dart-review.googlesource.com/c/85163
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Both the mutator as well as the background compiler are accessing constants
arrays attached to [Script] objects, which can cause races where mutator is
modifying the hashmap while the background compiler is reading.
This CL adds locking around those accesses.
Change-Id: Iac7bbbe242d13b964698ae95fe1653fb4ce28a36
Reviewed-on: https://dart-review.googlesource.com/c/84903
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
During VM shutdown generally, or during killing isolate more
specifically, OOB messages will be sent to the isolate which cause an
[UnwindError] to be raised.
This error has to be propgated through as many dart frames and runtime
frames there are **until the very end**, namely to the event loop.
Currently the constant evaluator was sometimes wrapping [UnwindError]s
into [LanguageError]s which caused unwinding to stop, leaving us
kernel-isolate/service-isolate hanging around instead of shutting down.
Change-Id: Iade46aff3ca3459ec53f155b4f40305050380a7b
Reviewed-on: https://dart-review.googlesource.com/c/84904
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This is a reland of 1a4cff1bd4
Original change's description:
> [VM] Remove unused flags
>
> Remove the following flags which are always ON
> --strong
> --reify_generic_functions
>
> and these flags which are not applicable anymore
> --error-on-bad-override
> --error-on-bad-type
> --enable-type-checks
>
> Change-Id: I6e1aeb68e663953f4ae49ca94ea0daa87b661900
> Reviewed-on: https://dart-review.googlesource.com/c/79431
> Commit-Queue: Siva Annamalai <asiva@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Régis Crelier <regis@google.com>
Change-Id: Ib4452c22fb05eed38820708abb648939e03b1df0
Reviewed-on: https://dart-review.googlesource.com/c/84923
Reviewed-by: Siva Annamalai <asiva@google.com>
Remove the following flags which are always ON
--strong
--reify_generic_functions
and these flags which are not applicable anymore
--error-on-bad-override
--error-on-bad-type
--enable-type-checks
Change-Id: I6e1aeb68e663953f4ae49ca94ea0daa87b661900
Reviewed-on: https://dart-review.googlesource.com/c/79431
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Régis Crelier