- Weaken assert for identity reloads to account for lazy finalization.
- Store actual field end positions instead of computing from a terminating semicolon.
- Consider unfinalized classes to be unchanged if they have same sequence of tokens.
Change-Id: I3fcd7fed924bfac47dc382702ce63207bb8aa031
Reviewed-on: https://dart-review.googlesource.com/8164
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This reverts commit 68a727fa5c.
Revert "Fix ICData::New() invocation. Follow-up to 68a727fa5cf5."
This reverts commit ac06b1c8ea.
Revert "Fix last ICData::New() invocation. Follow-up to 68a727fa5cf5."
This reverts commit da26ffc4de.
Bug:
Change-Id: Ia2d4e6a3c3a3a329982c90aded11e72bf25a9a34
Reviewed-on: https://dart-review.googlesource.com/8402
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Reload rule describes how inline cache has to be processed during hot reload, whether it should
be updated, reset or preserved.
Bug: dartbug.com/30639
Change-Id: I40b63ade786456ec48d4fa205a076654c2996bce
Reviewed-on: https://dart-review.googlesource.com/7586
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@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>
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>
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>
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>
Obfuscation is controlled by obfuscate flag in Dart_IsolateFlags.
Obfuscation of identifiers is performed during script tokenization - when TokenStream is generated from the source. All kIDENT and kINTERPOL_VAR tokens are renamed consistently using a persistent obfuscation map stored in ObjectStore::obfuscation_map.
Some identifiers (pseudo-keywords, arithmetic operators, builtin recognized methods and entry-points) are not renamed to keep name based lookups from breaking. All other identifiers are renamed.
Constant instances of Symbol-s (both created via literal syntax #ident and using constant constructor const Symbol("ident")) are renamed consistently with corresponding identifiers.
Script urls and Library urls and names are also obfuscated.
Obfuscation map can be dumped as a JSON array at the end of precompilation using Dart_GetObfuscationMap API.
BUG=https://github.com/dart-lang/sdk/issues/30524R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/3003583002 .
We were only recording metadata positions when mirrors were enabled. Mirrors are not enabled for AOT, so this metadata became unavailable to the inliner. Now we always record metadata position.
The tree-shaker has been updated to know how to remove the metadata.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/3003183003 .
This CL copies the kernel bodies for all functions and
fields into the VM heap. The function bodies in the VM
heap are then used when compiling the flowgraphs.
This theoretically means that the malloc'd data can be
freed and that snapshotting from kernel could possibly
work, though it hasn't been tested.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2972343002 .
Reapply 3d4838fc70 with the following
modifications:
* define PRIX64 to fix compilation errors on Windows;
* add and use short form format specifiers PX and PX64 to make it
uniform with other format specifiers.
Original review: https://codereview.chromium.org/2987183002
Description of the original CL:
Until this change, implementation of Dart_IntegerToHexCString()
always created Bigint objects and used Bigint::ToHexCString() to do
the work.
In --limit-ints-to-64-bits mode (with Dart integers limited to 64
bits) Bigints are banned and should not be used.
This CL revises Dart_IntegerToHexCString implementation to avoid
creating Bigint objects for Smi and Mint arguments, so it would
work in --limit-ints-to-64-bits mode.
Also, this CL adds test case to lock down the behavior of
Dart_IntegerToHexCString.
R=zra@google.com
Issue: https://github.com/dart-lang/sdk/issues/30103
Review-Url: https://codereview.chromium.org/2985423002 .
Until this change, implementation of Dart_IntegerToHexCString()
always created Bigint objects and used Bigint::ToHexCString() to do
the work.
In --limit-ints-to-64-bits mode (with Dart integers limited to 64
bits) Bigints are banned and should not be used.
This CL revises Dart_IntegerToHexCString implementation to avoid
creating Bigint objects for Smi and Mint arguments, so it would
work in --limit-ints-to-64-bits mode.
Also, this CL adds test case to lock down the behavior of
Dart_IntegerToHexCString.
R=asiva@google.com
Issue: https://github.com/dart-lang/sdk/issues/30103
Review-Url: https://codereview.chromium.org/2987183002 .
The TypedData_getUint64 native method is used to implement Uint64List
and ByteData.getUint64().
When running in --limit-ints-to-64-bits mode (with Dart integers
limited to 64 bits), this native method and its clients should
silently cast values (with wrap-around) to signed 64-bit integer.
This is the intended behavior, chosen to make it possible to work
with arbitrary data.
This CL changes underlying Integer::NewFromUint64() to do the silent
conversion instead of returning Integer::null().
Another client of Integer::NewFromUint64, Dart_NewIntegerFromUint64 is
changed to handle error without relying on Integer::NewFromUint64().
R=zra@google.com
Issue: https://github.com/dart-lang/sdk/issues/30103
Review-Url: https://codereview.chromium.org/2992013002 .
This is the re-application of 44e8da3ecd
with fixes:
* Dartanalyzer error is fixed in the new test isolate/message4_test
* The new test is skipped in the status file in dart2j/non-d8 modes,
issue #30247 is created.
* Minor tweak of Closure_equals: other.IsClosure() is tested earlier.
Original CL review:
https://codereview.chromium.org/2989493002/
Original CL description:
This CL introduces a new Function kind, kImplicitClosureFunction, in
order to simplify check for implicit closures and make it more
efficient.
This CL also fixes Function::IsImplicitStaticClosureFunction(RawFunction*)
to correctly handle implicit closures created from static native
functions.
Closes#30203.
As the result of a faster check for implicit closures and slight
refactoring of Closure_equals, micro-benchmark exercising Closure_equals
speeds up from 9618ms to 6700ms for implicit closures case and
insignificantly for other cases.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2987703002 .
This CL introduces a new Function kind, kImplicitClosureFunction, in
order to simplify check for implicit closures and make it more
efficient.
This CL also fixes Function::IsImplicitStaticClosureFunction(RawFunction*)
to correctly handle implicit closures created from static native
functions.
Closes#30203.
As the result of a faster check for implicit closures and slight
refactoring of Closure_equals, micro-benchmark exercising Closure_equals
speeds up from 9618ms to 6700ms for implicit closures case and
insignificantly for other cases.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2989493002 .
The closure-conversion transformation is not enabled yet. This commit
only adds the support for it to FlowGraphBuilder and
StreamingFlowGraphBuilder. More work should be done before enabling the
transformation; most mportantly, the 'platform.dill' file that is used
in the Kernel isolate and is loaded by VM for linking with executed
programs should be separated. The former should receive a file not
touched by the transformation, and the latter should receive a
transformed one.
BUG=
R=jensj@google.com, karlklose@google.com, kustermann@google.com
Review-Url: https://codereview.chromium.org/2891053003 .
This CL includes the following fixes:
* Fix for incorrect non-nullable assumption about _Closure._hash field.
* Add error handling into BecomeMapTraits::Hash.
* Correct assertions for validating layout of Closure objects.
* Add identityHashCode to the list of VM entry points in precompiler.
Closes#30211.
Original code review:
https://codereview.chromium.org/2983823002/
Original CL description:
This performance improvement is inspired by Flutter listeners stored in
the HashSet (see ObserverList) and frequently checked using
HashSet.contains(). If there are many such listeners and they are
implicit instance closures (for example, created by
'new Listenable.merge(...)'), HashSet.contains() becomes very slow.
It spends a lot of time in Closure_equals native method due to hash
collisions between closure objects with same function
but different receivers.
This CL improves hashCode() calculation for implicit instance closures
by mixing function hashcode with identity hashcode of the receiver.
For explicit closures and static implicit closures hashCode() is
improved by using identityHashCode() of a closure object.
Also, hashcode is calculated once and cached in each closure instance.
The size of a closure instance doesn't grow up because there was unused
word-size padding both on 32-bit and 64-bit architectures.
The execution time of the following micro-benchmark is reduced from
47665ms to 135ms on my Linux/x64 box.
-------------------------------------
import "dart:collection";
class Foo {
int _a;
Foo(this._a);
void bar() {}
}
main() {
HashSet hs = new HashSet();
for (int i = 0; i < 1000; ++i) {
hs.add(new Foo(i).bar);
}
var watch = new Stopwatch()..start();
for (int i = 0; i < 1000; ++i) {
for (var c in hs) {
hs.contains(c);
}
}
int time = watch.elapsedMilliseconds;
print("Time: ${time}ms\n");
}
-------------------------------------
R=zra@google.com
Review-Url: https://codereview.chromium.org/2988493002 .
This performance improvement is inspired by Flutter listeners stored in
the HashSet (see ObserverList) and frequently checked using
HashSet.contains(). If there are many such listeners and they are
implicit instance closures (for example, created by
'new Listenable.merge(...)'), HashSet.contains() becomes very slow.
It spends a lot of time in Closure_equals native method due to hash
collisions between closure objects with same function
but different receivers.
This CL improves hashCode() calculation for implicit instance closures
by mixing function hashcode with identity hashcode of the receiver.
For explicit closures and static implicit closures hashCode() is
improved by using identityHashCode() of a closure object.
Also, hashcode is calculated once and cached in each closure instance.
The size of a closure instance doesn't grow up because there was unused
word-size padding both on 32-bit and 64-bit architectures.
The execution time of the following micro-benchmark is reduced from
47665ms to 135ms on my Linux/x64 box.
-------------------------------------
import "dart:collection";
class Foo {
int _a;
Foo(this._a);
void bar() {}
}
main() {
HashSet hs = new HashSet();
for (int i = 0; i < 1000; ++i) {
hs.add(new Foo(i).bar);
}
var watch = new Stopwatch()..start();
for (int i = 0; i < 1000; ++i) {
for (var c in hs) {
hs.contains(c);
}
}
int time = watch.elapsedMilliseconds;
print("Time: ${time}ms\n");
}
-------------------------------------
R=rmacnak@google.com, zra@google.com
Review-Url: https://codereview.chromium.org/2983823002 .
result type that may contain a generic function type.
Add a regression test demonstrating the fixed problem.
Rename ResolveType to ResolveTypeParameters in the parser to clarify that only
type parameters get resolved.
Rename ResolveSignature to ResolveSignatureTypeParameters for the same reason.
Correctly propagate the finalization mode when finalizing signatures.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2979763002 .
This is the 2nd attempt to land the CL
abed3c2a70
Original review: https://codereview.chromium.org/2982823002
No extra changes were made. Large literals in the Dart core library
which caused failures during the previous attempt to land this CL have
been fixed separately.
Description of the CL:
In --limit-ints-to-64-bits mode:
* Integer constructors return Integer::null if integer is out of range.
* Error is reported for integer literals which are out of range.
* Dart API is revised to return errors if integers are out of range.
Bigint::IsDisabled() method is introduced to be able to enable/disable
Bigints independently of --limit-ints-to-64-bits mode in future.
Deprecated constructor Integer::NewFromUint64 is replaced with
Integer::New in certain cases.
R=regis@google.com
Issue: https://github.com/dart-lang/sdk/issues/30103
Review-Url: https://codereview.chromium.org/2980223002 .
In --limit-ints-to-64-bits mode:
* Integer constructors return Integer::null if integer is out of range.
* Error is reported for integer literals which are out of range.
* Dart API is revised to return errors if integers are out of range.
Bigint::IsDisabled() method is introduced to be able to enable/disable
Bigints independently of --limit-ints-to-64-bits mode in future.
Deprecated constructor Integer::NewFromUint64 is replaced with
Integer::New in certain cases.
R=zra@google.com
Issue: https://github.com/dart-lang/sdk/issues/30103
Review-Url: https://codereview.chromium.org/2982823002 .
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 .
Do not consider a generic function type as uninstantiated if all the function
type parameters appearing in its signature are declared by the type itself.
The generic function type is uninstantiated if it refers to function type
parameters of parent generic functions, or to class type parameters.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2965743002 .
Régis Crelier