Previously, the string set up by the embedder was eagerly passed to
Uri.parse during Isolate startup. This is expensive both in time and
memory footprint. This CL causes Uri.parse() to be called only
when needed. This change will allow reducing the memory footprint
of Fuchsia's Dart content handler on hello world by ~1MB.
fixes#25603R=asiva@google.com
Review-Url: https://codereview.chromium.org/2988613002 .
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 .
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 .
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 .
Proper sequencing of _asyncStackTraceHelper in Kernel
This helper function was being called before its argument was
initialized so it was passing null. Instead, it should be called
after its argument is initialized.
Because the initialization happens in Kernel code, it is simplest to
insert the call explicitly in Kernel code as well as part of the async
transformation. This has the consequence that we now call the helper
function even when the flag causal_async_stacks is false.
Fixes issue #29771.
Fixes issue #30178
Fixes issue #30058
BUG=
R=aam@google.com, asiva@google.com
Review-Url: https://codereview.chromium.org/2936793003 .
Review-Url: https://codereview.chromium.org/2982943002 .
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 .
This changeset revises --limit-ints-to-64-bits option to
change range of integers from unlimited to int64.
On overflow, integer arithmetic operations silently wrap around and
discard extra bits. No Bigints are allocated in case of overflow.
This changeset is the 1st part in the series of changes, it revises the implementation of integer arithmetic operations. More changes will follow.
R=regis@google.com, zra@google.com
Issue: https://github.com/dart-lang/sdk/issues/30103
Review-Url: https://codereview.chromium.org/2974633003 .
Array Bounds Check Generalization pass attempts to hoist CheckArrayBound
instructions out of loops by generalizing them: for example in the loop
like
for (var i = 0; i < L; i++) {
// a[i]
CheckArrayBound(i, a.length)
LoadIndexed(a, i)
}
we hoist CheckArrayBound(i, a.length) by turning it into
CheckArrayBound(L - 1, a.length):
CheckArrayBound(L - 1, a.length)
for (var i = 0; i < L; i++) {
// a[i]
LoadIndexed(a, i)
}
However this leads to deoptimizations if the loop never executes: e.g. if
L = 0 then L - 1 is -1 which does not pass generalized bounds check.
We prevent repeated deoptimizations by disabling this optimization if any
of the generalized bounds checks deoptimizes. However this does not work
as intended because we only check this flag on an outermost function, so
if function with a problematic bounds check get inlined into a lot of places
it ends up causing a lot of deoptimizations in different places.
This is why cec963f028 caused performance issues
in dartdoc: _GrowableList._grow is now called with length == 0 whenever we
add an element to an empty list. This causes deoptimization in a lot of different
functions in dartdoc because _GrowableList._grow ends up inlined into a lot
of different places.
Fixes https://github.com/dart-lang/sdk/issues/30090
This CL will be reverted once a better solution for the underlying problem is in place (tracked by https://github.com/dart-lang/sdk/issues/30102)
BUG=
R=askesc@google.com, erikcorry@google.com
Review-Url: https://codereview.chromium.org/2971303002 .
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 .
Terry Lucas