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>
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>
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
Change-Id: I6d33d4ca3d5187a1eb1664078c003061855f0160
Reviewed-on: https://dart-review.googlesource.com/50482
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@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
Change-Id: I44a1d5d4b27454ae026aef2a301aada3dd399ea0
Reviewed-on: https://dart-review.googlesource.com/49861
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
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.
Issue https://github.com/dart-lang/sdk/issues/31798
Change-Id: I174a11b3b812799f399a60af799144c2ba3c26ec
Reviewed-on: https://dart-review.googlesource.com/44787
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Régis Crelier <regis@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>
The compactor copies all live objects in old space to fresh pages, places forwarding pointers in the old objects, forwards all the pointers, then frees the old pages. This has a high space overhead. It is not meant for use in production, but meant to test that the VM is properly set up to handle old-space objects moving.
Large page objects and instruction objects are not moved.
Bug: https://github.com/dart-lang/sdk/issues/30978
Change-Id: Ia42683fd5e27a33702aa5e83bece803a8b005a4b
Reviewed-on: https://dart-review.googlesource.com/13624
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Erik Corry <erikcorry@google.com>
This reverts commit e76ea5b604.
1. Remove unused dart debugger API entrypoints which are not used anymore
as this API has been deprecated and dartium was the last user.
2. Some unit tests are using some of these API entrypoints, so moved them
over to a test file which will be linked into run_vm_tests
Change-Id: I5a486b98e4b97eb4df2e58d9cc0ba603e96c2e32
Reviewed-on: https://dart-review.googlesource.com/11180
Reviewed-by: Siva Annamalai <asiva@google.com>
as this API has been deprecated and dartium was the last user.
2. Some unit tests are using some of these API entrypoints, so moved them
over to a test file which will be linked into run_vm_tests
Change-Id: I3343b23d082400da3c803cf81ea80dfaa5e426cf
Reviewed-on: https://dart-review.googlesource.com/7942
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Originally these passes were a single confusingly named flow_graph_optimizer
pass, they later were completely split by duplicating flow_graph_optimizer
twice as jit_optimizer.cc and aot_optimizer.cc and tweaking them in few
places.
Duplication has been done in anticipation that these passes will diverge
considerably, however simple diffing reveals that in 2 years they have
not actually diverged much at all.
Diffing also reveals numerous bugs and inconsistencies between jit_optimizer
and aot_optimizer.
It does not make sense to keep these files duplicated so this change merges
them back together - extracting most of their common behaviour into
CallSpecializer base class.
The separation is not entirely clean - for simplicity we introduce
the knowledge about precompiled_mode into CallSpecializer base class.
You can look for FLAG_precompiled_mode and FLAG_use_field_guards in the
call_specializer.cc to see where base class has to be aware about both AOT and
JIT mode.
This change also renames XyzOptimizer to XyzCallSpecializer because the main
optimization these classes were doing was specialization of calls based on
type feedback or inferred types.
Bug: https://github.com/dart-lang/sdk/issues/30575
Change-Id: I0b062c4b7549d08b1bee9303d92a3fb549f54e21
Reviewed-on: https://dart-review.googlesource.com/3640
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
New folder structure (nested under vm/):
- compiler/
- jit/ - JIT specific code
- aot/ - AOT specific code
- backend/ - all middle-end and back-end code (IL, flow graph)
- assembler/ - assemblers and disassemblers
- frontend/ - front ends (AST -> IL, Kernel -> IL)
compiler/README.md would be the documentation root for the compiler
pipeline
Bug: https://github.com/dart-lang/sdk/issues/30575
Change-Id: I2dfd9688793bff737f7632ddc77fca766875ce36
Reviewed-on: https://dart-review.googlesource.com/2940
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
There already exists a class named "Reader" in the "kernel" namespace
which reads bytes from a kernel binary. The class KernelLoader
(KernelReader before this change) creates VM heap objects and populates
them.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/3010543002 .
Alexander Aprelev