If there is registered expression compiler, VM debugger uses it to compile expressions. Otherwise, it will fallback to use kernel service compiler.
This is needed to support Flutter use case where compiler is running on developer's host machine, not on the device where VM is running.
Bug: dartbug.com/31981
Change-Id: I8bdfc8ab45a57c306169abe189f1e24e1b0bcf40
Reviewed-on: https://dart-review.googlesource.com/57520
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
- Remove a level of indirection when accessing code units.
- Require a finalizer when constructing an external string.
Change-Id: I3f65246bf0ac50ffad900e2c338623a7684a9d3d
Reviewed-on: https://dart-review.googlesource.com/54300
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Relanding 4be50d6fa1 with fixes to DBC
and location summaries: AssertAssignable must save FPU registers.
For now we are limiting this to type checks against type parameter types.
In Dart 1 mode Dart2JS compiles itself in 28s when running from source
and in 23s when running from ideal app-jit snapshot (trained on the
same workload).
Before this change in Dart 2 mode numbers were 51s and 57s respectively.
After this change in Dart 2 mode numbers are 38s and 32s. Meaning
that regression is reduced by 50%.
Issue https://github.com/dart-lang/sdk/issues/31798
Issue https://github.com/dart-lang/sdk/issues/33257
Change-Id: Ifb55f86453bfdf36a2e03bcd7f3197cfde257103
Reviewed-on: https://dart-review.googlesource.com/57980
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This reverts commit 4be50d6fa1.
Reason for revert: Failures on SIMDBC64 and Analyzer bots.
Original change's description:
> [vm] Enable type stubs based type checks in JIT mode for some types.
>
> For now we are limiting this to type checks against type parameter types.
>
> # Performance improvements
>
> In Dart 1 mode Dart2JS compiles itself in 28s when running from source
> and in 23s when running from ideal app-jit snapshot (trained on the
> same workload).
>
> Before this change in Dart 2 mode numbers were 51s and 57s respectively.
>
> After this change in Dart 2 mode numbers are 38s and 32s. Meaning
> that regression is reduced by 50%.
>
> Issue https://github.com/dart-lang/sdk/issues/31798
> Issue https://github.com/dart-lang/sdk/issues/33257
>
> Change-Id: I34bf5385a5cc3c7702dc281c6dfa89da85d3dde1
> Reviewed-on: https://dart-review.googlesource.com/57601
> Reviewed-by: Régis Crelier <regis@google.com>
> Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,kustermann@google.com,regis@google.com
Change-Id: I85a30c962b0cd556310e19193f5993ab76ecf2e7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/57840
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
For now we are limiting this to type checks against type parameter types.
# Performance improvements
In Dart 1 mode Dart2JS compiles itself in 28s when running from source
and in 23s when running from ideal app-jit snapshot (trained on the
same workload).
Before this change in Dart 2 mode numbers were 51s and 57s respectively.
After this change in Dart 2 mode numbers are 38s and 32s. Meaning
that regression is reduced by 50%.
Issue https://github.com/dart-lang/sdk/issues/31798
Issue https://github.com/dart-lang/sdk/issues/33257
Change-Id: I34bf5385a5cc3c7702dc281c6dfa89da85d3dde1
Reviewed-on: https://dart-review.googlesource.com/57601
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Fixes#33170: We had an assert that type variables are not bounded by "dynamic".
This assert was previously valid because the FE replaces "extends dynamic" with
"extends Object". However, it's not necessary in any way, and it's difficult to
access the Object type from outside the FE when synthesizing type parameters for
expression compilation.
Fixes#33171: The synthetic class generated during serialization to hold the
synthetic method may need to extend core library classes if the expression's
scope was within a core library class. In this case, the class finalizer needs
to avoid applying the restrictions on class extension to the synthetic class.
To facilitate this, we now use a single class name for all synthetic classes,
rather than copying the original class name. The name of the synthetic class has
no function at all, since the synthetic method is reparented to the original
class before execution.
Fixes#33239: The arguments descriptor passed to InvokeFunction for expression
functions which capture generic type parameters was using the wrong argument
count.
Fixes#33270: Use LookupClassAllowPrivate instead of LookupClass when resolving
the expression's scope in the VM.
Test Plan:
#33170: python tools/test.py -m debug -c dartk --strong service/evaluate_function_type_parameters_test
#33171: python tools/test.py -m debug -c dartk --strong service/eval_test
#33239: Updated "evaluate_function_type_parameters_test.dart".
#33270: Updated "eval_test.dart".
Change-Id: I376926bddd2224ec2322b43685d6c13831f1a8e7
Reviewed-on: https://dart-review.googlesource.com/56060
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
We recently removed two kind bits from `Function` to free up space for other
bits. This left two bits in `RawFunction::kind_tag_` unused and no longer
deterministically initialized. This caused `Function` objects saved in the
snapshot within the `.rodata` section of the `dart` binary to be serialized with
a non-deterministic kind tag. We now zero-initialize the kind tag.
# Test Plan
I built the `runtime` target (which includes `dart`) 10 times locally and
received the same SHA256 hash for `dart` each time.
Change-Id: Ib0de4b4b040e26a92a1ba3364460bcec0f665789
Reviewed-on: https://dart-review.googlesource.com/57624
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When the constant transformation is enabled on annotations, we need to fix handling
of @ExternalName annotations in the kernel_loader to ensure that we are setting
is_external = false on native methods.
The original revision is in patchset 1.
# Test Plan
The only regression was on benchmarks, Golem results are pending.
Change-Id: Ib80bb9f532299056e770a3b378cc5ad9ee451f57
Reviewed-on: https://dart-review.googlesource.com/56960
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Kernel mixin transformation desugars mixin applications into normal
classes. Mixed-in type is pulled into interfaces list.
However, dart:mirrors needs to know the original mixed-in type of
a mixin application.
This change solves this problem by propagating a 'isTransformedMixinApplication'
attribute of a class through kernel AST, kernel binary and VM objects
into dart:mirrors implementation.
Fixes: https://github.com/dart-lang/sdk/issues/33240
Change-Id: I98ca69294e1ad445402a5ca91d90c30447aabcb2
Reviewed-on: https://dart-review.googlesource.com/56721
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This reverts commit 3e50ea32b5.
Reason for revert: Severe performance regressions on many aot-v2 benchmarks.
Original change's description:
> [vm] Support definition of entry-points via @pragma('vm.extern') annotations.
>
> The `@pragma` annotations are evaluated by the constants transformation and
> visible to TFA and the precompiler, which match on the "options" field of the
> annotation to determine whether to mark the class/procedure as a root.
>
> This required enabling the transformation of annotation constants by default.
>
> # Test Plan
>
> The "vmservice_io.main" entry-point is removed from `main.cc` and annotated with
> `@pragma`. All precompiler tests will crash if "vmservice_io.main" is not
> available at runtime.
>
> Debug/release precompiler bots are visible in "cl-linux" button.
>
> Change-Id: I03c5d6ba7918672ed9905fcaee8dabe675a93a5d
> Reviewed-on: https://dart-review.googlesource.com/56660
> Commit-Queue: Samir Jindel <sjindel@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,alexmarkov@google.com,sjindel@google.com
Change-Id: I779c17d003659129a4b3fcf284423104948f60e2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/56820
Reviewed-by: Samir Jindel <sjindel@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
The `@pragma` annotations are evaluated by the constants transformation and
visible to TFA and the precompiler, which match on the "options" field of the
annotation to determine whether to mark the class/procedure as a root.
This required enabling the transformation of annotation constants by default.
# Test Plan
The "vmservice_io.main" entry-point is removed from `main.cc` and annotated with
`@pragma`. All precompiler tests will crash if "vmservice_io.main" is not
available at runtime.
Debug/release precompiler bots are visible in "cl-linux" button.
Change-Id: I03c5d6ba7918672ed9905fcaee8dabe675a93a5d
Reviewed-on: https://dart-review.googlesource.com/56660
Commit-Queue: Samir Jindel <sjindel@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>
Update status for simulators, which the test harness invokes with DIL files instead of source files.
Change-Id: I8444ad7e17a0a71a1ce3c0021487397baa1c3e65
Reviewed-on: https://dart-review.googlesource.com/54622
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This code is unused and has been bit-rotting for some time, so we'll
remove support for the kVector{Create,Copy,Get,Set}/kClosureCreation
kernel expressions.
Change-Id: Ie83d35b6d2cd533f3c08084631c5faf0c14ff122
Reviewed-on: https://dart-review.googlesource.com/53940
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
In addition, this removes support for seeding the VM isolate snapshot with Instructions and referencing those Instructions in the isolate snapshot. This was leftover from an earlier experiment to share Instructions between a Core-JIT snapshot and App-JIT snapshots. Removing this reclaims the sign bit on Instruction offsets.
Add missing cases to TypeTestingStubFinder::StubNameFromAddresss.
Change-Id: Ie87216b4e284db1dc3eddb12f38ddbe8a841d312
Reviewed-on: https://dart-review.googlesource.com/50620
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Our generated code does not keep the context in a special register
anymore (for quite some time now). The context is just another definition
in the IR language and gets assigned register locations by the linearscan
register allocator.
Furthermore we no longer use an empty context for closures which have no
captured states, instead the context of those closures is just `null`.
This CL therefore removes Object::empty_context() and the CTX constant.
Change-Id: Iea171e0d0fd56c48f1c456e08e060a12267e39cc
Reviewed-on: https://dart-review.googlesource.com/51129
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Original revision is in Patchset 1.
Run against failing kernel-precomp tests in "cl-linux-try".
Change-Id: I997de294150ef7dd0874eeccb8b6187ae64ea813
Reviewed-on: https://dart-review.googlesource.com/51220
Reviewed-by: Erik Corry <erikcorry@google.com>
Relands 165c583d57
[VM] Introduction of type testing stubs - Part 1
This CL:
* Adds a field to [RawAbstractType] which will always hold a pointer
to the entrypoint of a type testing stub
* Makes this new field be initialized to a default stub whenever a
instances are created (e.g. via Type::New(), snapshot reader, ...)
* Makes the clustered snapshotter write a reference to the
corresponding [RawInstructions] object when writing the field and do
the reverse when reading it.
* Makes us call the type testing stub for performing assert-assignable
checks.
To reduce unnecessary loads on callsites, we store the entrypoint of the
type testing stubs directly in the type objects. This means that the
caller of type testing stubs can simply branch there without populating
a code object first. This also means that the type testing stubs
themselves have no access to a pool and we therefore also don't hold on
to the [Code] object, only the [Instruction] object is necessary.
The type testing stubs do not setup a frame themselves and also have no
safepoint. In the case when the type testing stubs could not determine
a positive answer they will tail-call a general-purpose stub.
The general-purpose stub sets up a stub frame, tries to consult a
[SubtypeTestCache] and bails out to runtime if this was unsuccessful.
This CL is just the the first, for ease of reviewing. The actual
type-specialized type testing stubs will be generated in later CLs.
Reviewed-on: https://dart-review.googlesource.com/44787
Relands f226c22424
[VM] Introduction of type testing stubs - Part 2
This CL starts building type testing stubs specialzed for [Type] objects
we test against.
More specifically, it adds support for:
* Handling obvious fast cases on the call sites (while still having a
call to stub for negative case)
* Handling type tests against type parameters, by loading the value
of the type parameter on the call sites and invoking it's type testing stub.
* Specialzed type testing stubs for instantiated types where we can
do [CidRange]-based subtype-checks.
==> e.g. String/List<dynamic>
* Specialzed type testing stubs for instantiated types where we can
do [CidRange]-based subclass-checks for the class and
[CidRange]-based subtype-checks for the type arguments.
==> e.g. Widget<State>, where we know [Widget] is only extended and not
implemented.
* Specialzed type testing stubs for certain non-instantiated types where we
can do [CidRange]-based subclass-checks for the class and
[CidRange]-based subtype-checks for the instantiated type arguments and
cid based comparisons for type parameters. (Note that this fast-case migth
result in some false-negatives!)
==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only
extended and not implemented.
This optimizes cases where the caller uses `new HashMap<A, B>()` and only
uses `A` and `B` as key/values (and not subclasses of it). The false-negative
can occur when subtypes of A or B are used. In such cases we fall back to the
[SubtypeTestCache]-based imlementation.
Reviewed-on: https://dart-review.googlesource.com/44788
Relands 25f98bcc75
[VM] Introduction of type testing stubs - Part 3
The changes include:
* Make AssertAssignableInstr no longer have a call-summary, which
helps methods with several parameter checks by not having to
re-load/re-initialize type arguments registers
* Lazily create SubtypeTestCaches: We already go to runtime to warm up
the caches, so we now also create the caches on the first runtime
call and patch the pool entries.
* No longer load the destination name into a register: We only need
the name when we throw an exception, so it is not on the hot path.
Instead we let the runtime look at the call site, decoding a pool
index from the instructions stream. The destination name will be
available in the pool, at a consecutive index to the subtype cache.
* Remove the fall-through to N=1 case for probing subtypeing tests,
since those will always be handled by the optimized stubs.
* Do not generate optimized stubs for FutureOr<T> (so far it just
falled-through to TTS). We can make optimzed version of that later,
but it requires special subtyping rules.
* Local code quality improvement in the type-testing-stubs: Avoid
extra jump at last case of cid-class-range checks.
There are still a number of optimization opportunities we can do in
future changes.
Reviewed-on: https://dart-review.googlesource.com/46984
Relands 2c52480ec8
[VM] Introduction of type testing stubs - Part 4
In order to avoid generating type testing stubs for too many types in
the system - and thereby potentially cause an increase in code size -
this change introduces a smarter way to decide for which types we should
generate optimized type testing stubs.
The precompiler creates a [TypeUsageInfo] which we use to collect
information. More specifically:
a) We collect the destination types for all type checks we emit
(we do this inside AssertAssignableInstr::EmitNativeCode).
-> These are types we might want to generate optimized type testing
stubs for.
b) We collect type argument vectors used in instance creations (we do
this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
of used type argument vectors for each class.
After the precompiler has finished compiling normal code we scan the set
of destination types collected in a) for uninstantiated types (or more
specifically, type parameter types).
We then propagate the type argument vectors used on object allocation sites,
which were collected in b), in order to find out what kind of types are flowing
into those type parameters.
This allows us to extend the set of types which we test against, by
adding the types that flow into type parameters.
We use this final augmented set of destination types as a "filter" when
making the decision whether to generate an optimized type testing stub
for a given type.
Reviewed-on: https://dart-review.googlesource.com/48640
Issue https://github.com/dart-lang/sdk/issues/32603
Closes https://github.com/dart-lang/sdk/issues/32852
Change-Id: Ib79fbe7f043aa88f32bddad62d7656c638914b44
Reviewed-on: https://dart-review.googlesource.com/50944
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Alexander Aprelev