Update status files.
This cl includes implementing these two features on all platforms:
1) Support calling generic functions via DartEntry::InvokeFunction().
2) Support native generic functions. These are currently allowed, but type
arguments are ignored, and therefore not accessible from the C++ side.
Change-Id: Id39e8ca46c2ba1ba3d46946c16712a8572ff64ea
Reviewed-on: https://dart-review.googlesource.com/34023
Commit-Queue: Régis Crelier <regis@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
If we know that receiver is a subclass of a certain type and that this
type has accessor get:m then call o.m(...) is guaranteed to be an
invocation through a getter. Such invocations are executed most
efficiently when expanded into o.get:m().call(...).
Source based pipeline handles this case (at least for invocations on
`this`) directly in the parser, but Kernel based graph builder does not
have this sort of special case.
Instead of teaching Kernel flow graph builder to specially handle
invocations on `this` we teach AOT call specializer to specially handle
all invocations where receiver is known to be a subclass of certain
class. Such optimization is more generic and handles things that
previously were not handled by the optimization.
AOT compiler also has heuristics for injecting field dispatchers into
classes but these heuristics only handle fields of function type and
don't work for fields like `Function f` or `var f`.
Improves ParserCombinators benchmark by 4x.
This relands eea2c168f9 with a fix.
Change-Id: I13a41544c737b980efd431e31e4d15ad31da853e
Reviewed-on: https://dart-review.googlesource.com/30455
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
This reverts commit eea2c168f9.
Reason for revert: standalone_2/io/test_runner_test times out
python tools/test.py -m release -c precompiler -r dart_precompiled -a simarm64 --use-blobs standalone_2/io/test_runner_test
Original change's description:
> [vm] Detect and expand calls through getters in AOT call specializer.
>
> If we know that receiver is a subclass of a certain type and that this
> type has accessor get:m then call o.m(...) is guaranteed to be an
> invocation through a getter. Such invocations are executed most
> efficiently when expanded into o.get:m().call(...).
>
> Source based pipeline handles this case (at least for invocations on
> `this`) directly in the parser, but Kernel based graph builder does not
> have this sort of special case.
>
> Instead of teaching Kernel flow graph builder to specially handle
> invocations on `this` we teach AOT call specializer to specially handle
> all invocations where receiver is known to be a subclass of certain
> class. Such optimization is more generic and handles things that
> previously were not handled by the optimization.
>
> AOT compiler also has heuristics for injecting field dispatchers into
> classes but these heuristics only handle fields of function type and
> don't work for fields like `Function f` or `var f`.
>
> Improves ParserCombinators benchmark by 4x.
>
> Bug:
> Change-Id: I365d4fb2140577d02aefbf16fcf6be1bd12413a6
> Reviewed-on: https://dart-review.googlesource.com/29840
> Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
TBR=vegorov@google.com,kustermann@google.com,alexmarkov@google.com
Change-Id: I2b891b1674dd07fa43d6414428438c41e3332391
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/30400
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
If we know that receiver is a subclass of a certain type and that this
type has accessor get:m then call o.m(...) is guaranteed to be an
invocation through a getter. Such invocations are executed most
efficiently when expanded into o.get:m().call(...).
Source based pipeline handles this case (at least for invocations on
`this`) directly in the parser, but Kernel based graph builder does not
have this sort of special case.
Instead of teaching Kernel flow graph builder to specially handle
invocations on `this` we teach AOT call specializer to specially handle
all invocations where receiver is known to be a subclass of certain
class. Such optimization is more generic and handles things that
previously were not handled by the optimization.
AOT compiler also has heuristics for injecting field dispatchers into
classes but these heuristics only handle fields of function type and
don't work for fields like `Function f` or `var f`.
Improves ParserCombinators benchmark by 4x.
Bug:
Change-Id: I365d4fb2140577d02aefbf16fcf6be1bd12413a6
Reviewed-on: https://dart-review.googlesource.com/29840
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL improves performance of allocation statistic counters on ARM
by removing duplicated loads and increasing distance between dependent
loads. These statistic counters are part of allocator fast path in a
non-product mode.
This change improves performance of gestures/velocity_tracker_bench
Flutter micro-benchmark in 'flutter run --profile' mode:
Before: 3352 µs
After: 3156 µs (-5.8%)
(minimum of 5 runs)
Change-Id: Ic7998318d9ca3e7997379d0054faaf5b0b569bb6
Reviewed-on: https://dart-review.googlesource.com/15640
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Previously allocations of Arrays/TypedData from generated code would try to allocate objects of any size into new-space. These allocation sites would only end up allocating into old-space if new-space didn't have enough free space and the allocation takes the slow path into the runtime. This means the allocation space from generated code was unstable. This change makes the allocation policy consistent between generated code and C++: objects larger than kNewAllocatableSize are always allocated into old-space.
This change regresses the microbenchmarks Streams.callbacks and Streams.controller (-44% and -33% on x64) because they allocate large, short-lived arrays.
Change-Id: I81c65af305b45b6fd40ec81d4a4ddc015bfc039c
Reviewed-on: https://dart-review.googlesource.com/4300
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
reified generic function.
Clean up code to avoid similar issue in the future, i.e. make it clear whether
the passed type argument vector is counted or not by using better names.
Change-Id: I60fd6f6acb302235d8c1ae4f2bc4bf459724421e
Reviewed-on: https://dart-review.googlesource.com/3400
Reviewed-by: Ryan Macnak <rmacnak@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>
This is the first step to adding Thread Local Allocation Buffers to
the VM.
In this step, the mutator alone allocates to the new space, but keeps
track of the start and end of the space. This is akin to a single large
TLAB.
As a result, the generated code and the dbc simulator changed how they
allocate objects into the new space as well.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2980033002 .
This is the first step to adding Thread Local Allocation Buffers to
the VM.
In this step, the mutator alone allocates to the new space, but keeps
track of the start and end of the space. This is akin to a single large
TLAB.
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2951333002 .
Inline instance object hash code into object header on 64 bit.
64 bit objects have 32 bits of free space in the header word.
This is used for the hash code in string objects. We take it
for the default hash code on all objects that don't override
the hashCode getter.
This is both faster and a memory reduction. Eg it makes the
MegaHashCode part of the Megamorphic benchmark 6 times faster.
This is a reland of https://codereview.chromium.org/2954453002/
which fixes an issue that made script snapshots generated on
64 bit platforms incompatible with 32 bit VMs.
BUG=
R=vegorov@google.com
Review-Url: https://codereview.chromium.org/2965723002 .
Inline instance object hash code into object header on 64 bit.
64 bit objects have 32 bits of free space in the header word.
This is used for the hash code in string objects. We take it
for the default hash code on all objects that don't override
the hashCode getter.
This is both faster and a memory reduction. Eg it makes the
MegaHashCode part of the Megamorphic benchmark 6 times faster.
This is a reland of https://codereview.chromium.org/2912863006/
It fixes issues with the 32 bit compare-swap instruction on
ARM64 and fixes a fragile tree shaking test that is sensitive
to which private methods are in the core libraries.
R=kustermann@google.com, vegorov@google.com
BUG=
Review-Url: https://codereview.chromium.org/2954453002 .
64 bit objects have 32 bits of free space in the header word.
This is used for the hash code in string objects. We take it
for the default hash code on all objects that don't override
the hashCode getter.
This is both faster and a memory reduction. Eg it shaves about
70% off the running time of this microbenchmark:
List list = [];
class Thing {
get hashCode => 42;
}
class Thing2 {
get hashCode => 42;
}
class Thing3 { }
class Thing4 { }
main() {
int sum = 103;
for (int i = 0; i < 10000000; i++) {
list = [];
list.add("foo");
list.add(123);
list.add(1.23);
list.add(new Object());
list.add(new Thing());
list.add(new Thing2());
list.add(new Thing3());
list.add(new Thing4());
for (int j = 0; j < 2; j++) {
sum ^= biz(list);
}
}
print(sum);
}
int biz(List list) {
int sum = 103;
for (var x in list) {
sum ^= x.hashCode;
}
return sum;
}
R=rmacnak@google.com, vegorov@google.com
BUG=
Review-Url: https://codereview.chromium.org/2912863006 .
Do this in unoptimized code only, when --reify-generic-functions is specified.
This is still work in progress, and support in optimizer, in inliner, in DBC,
in kernel to ir, and other areas, will follow.
Many small fixes and added todos.
R=rmacnak@google.com, vegorov@google.com
Review-Url: https://codereview.chromium.org/2941643002 .
This moves the hash code into the header word for strings on 64 bit
platforms. With the old layout, 9 character strings became 48-byte
objects. With the new layout you have to go to 17 characters before
you are bumped from 4 to 6 words (32 to 48 bytes).
As a side effect, the class ID field is now 16 bits on all platforms
instead of having two different sizes, and the size field is 8 bits
on all platforms.
This also paves the way for moving the hash code for instance objects
into the header, so we won't need the side-lookup in the
hash-table-of-hash-codes on 64 bit platforms.
This is a reapplication of https://codereview.chromium.org/2893553002/
after issues were fixed in https://codereview.chromium.org/2888413002/
and https://codereview.chromium.org/2896583002/R=vegorov@google.com
BUG=
Review-Url: https://codereview.chromium.org/2895183002 .
This moves the hash code into the header word for strings on 64 bit
platforms. With the old layout, 9 character strings became 48-byte
objects. With the new layout you have to go to 17 characters before
you are bumped from 4 to 6 words (32 to 48 bytes).
As a side effect, the class ID field is now 16 bits on all platforms
instead of having two different sizes, and the size field is 8 bits
on all platforms.
This also paves the way for moving the hash code for instance objects
into the header, so we won't need the side-lookup in the
hash-table-of-hash-codes on 64 bit platforms.
R=vegorov@google.com
BUG=
Review-Url: https://codereview.chromium.org/2893553002 .
Add function_type_arguments field in closure instances.
Lots of other smaller changes, also related to generic function semantics.
This is still work in progress, with a change of direction in the design:
The type argument vector of a generic function will be prepended with the type
arguments of enclosing generic functions. The re-allocation and concatenation
will be done in nested generic function's prolog. This will greatly simplify
instantiation of types at run time without having to search the context for
parent function's type arguments. However, a closure instance now requires an
additional field. On the other hand, type parameters do not require a
parent_level field anymore.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2818273002 .
With generic methods, uninstantiated types will require 2 instantiators, one
reflecting the class type arguments (as of today) and one reflecting the
function type arguments (new).
This is work in progress and the second instantiator is always null for now.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2799373002 .
Simplify handling of closures as deferred objects.
The name "type_arguments_" is confusing, because class Closure is not generic.
Class Closure was forcefully made (kinda) generic by setting its
type_arguments_field_offset_in_words_ field to a valid value, so that the
type_arguments_ field in closure instances could be accessed similarly as in
generic instances. With generic functions, closures will potentially have more
than one instantiator and the name type_arguments_ becomes nonsensical.
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2719603002 .
This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.
Tracking causal stack traces:
- [x] Upon entry to an async function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix into the Thread.
- [x] Filter stack traces to remove async machinery.
Service protocol changes:
- [x] Send causal async stack trace.
Observatory changes:
- [x] Display causal async stack trace below async functions.
Fixes https://github.com/dart-lang/sdk/issues/27661R=asiva@google.com, rmacnak@google.com
Comparisons: https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiOGAZMly2ghTErALI/edit?usp=sharing
Review-Url: https://codereview.chromium.org/2646443005 .
Using two CMOVs for class ID load is not a win relative to a simple branch.
Unroll the loop that checks entries in the IC data to find correct call.
Don't check a counter for overflow on 64 bit, it's not going to happen and
even if it did it makes little difference.
Don't reload receiver and arg0 for every entry in the IC data in the
multidispatch case.
According to my measurements this IC stub is about 10% faster in the
single dispatch case, and about 15% faster in the less important double
dispatch case. Unoptimzed code spends about 30% of its time in these
two stubs.
R=regis@google.com
BUG=
Review-Url: https://codereview.chromium.org/2647913002 .
- Refactor the JumpToExceptionHandle code so that it is now built from
two pieces: JumpToFrame and RunExceptionHandler.
- Refactor the Simulator::Longjmp() code so that it is no longer
exception-specific. Instead it uses the RunExceptionHandler stub.
This makes it so that the JumpToFrame stub and Simulator::JumpToFrame
have the same semantics. This will make it easier to land the Rewind
changes I am working on.
There are some oddities for dbc.
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2503653002 .
Régis Crelier