With the current block size, this reduces space for forwarding information from two words per moved object to two words per (kObjectAlignment * kBitsPerWord) bytes of heap (1.6% on 64-bit, 3.1% on 32-bit).
dart2js compiling dart2js:
Compactor/Sweeper Runtime Max RSS
Sliding (binary search table) 105 s 1.085 GB
Sliding (bitvector) 57.8 s 998.566 MB
Evacuating 66.2 s 1.714 GB
Concurrent sweep 53.8 s 1.183 GB
Blocking sweep 55.0 s 1.181 GB
Bug: https://github.com/dart-lang/sdk/issues/30978
Change-Id: Ia6eec4f0162c3959154c5155df24cc06694ecac7
Reviewed-on: https://dart-review.googlesource.com/17721
Reviewed-by: Erik Corry <erikcorry@google.com>
This change brings down core snapshot size by ~750KB, and brings
down app-jit snapshot size of simple "Hello, World" dart script by
~650KB. The bot cycle times will also come down by around ~20%.
Change-Id: I2a01c98bedc7ebfa2a653983995486a71504daf3
Reviewed-on: https://dart-review.googlesource.com/16323
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Improves the space overhead of compaction from O(size of live objects) to O(number of live objects).
Future work includes:
- a smaller, faster representation the forwarding table via a bitmap of used allocation units
- sorting class sizes off-heap to allow sliding classes
- running forwarding in parallel
Removes unnecessary sweep from evacuating compactor.
Change-Id: If0991bfb75573201c6e8feed142ca0cc69fccab4
Bug: https://github.com/dart-lang/sdk/issues/30978
Reviewed-on: https://dart-review.googlesource.com/15988
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Erik Corry <erikcorry@google.com>
This new object points to program wide data like string offsets,
string data etc. It also holds an array of pointers to all Script
objects corresponding scripts in the program's source table.
This new object type is required for two reasons:
1. The Script objects now have a number of fields which point to
program wide data. All Script objects point to the same data in the
VM heap. By introducing an indirection via this new object, we reduce
the number of pointers in Script objects.
2. Lazy loading of VM objects - Kernel nodes of
entities like fields and functions have a field which point to the
source file in which they are defined. This entry is an index into
the program wide source table and helps in associating
functions/fields with their actual source location. When lazy loading
functions and fields, the pre-loaded script objects in the
program's KernelProgramInfo help in associating the functions and
fields with the correct source script at load time.
Change-Id: Id863284ae7dd98b0832e5dfc115dabad1ed762d8
Reviewed-on: https://dart-review.googlesource.com/13920
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Devirtualization optimization now adds metadata to kernel AST instead
of transforming nodes to Direct* ones. The direct call metadata
provides information about checking receiver for null, while
Direct* kernel nodes do not support null checking.
VM's kernel binary loader is extended to extract arbitrary metadata
from kernel binaries and keep it for flow graph builder.
Kernel flow graph builder is extended to take direct call metadata
into account and generate CheckNull/StaticCall instructions
for devirtualized PropertyGet, PropertySet and MethodInvocation nodes.
Issue: https://github.com/dart-lang/sdk/issues/30480
Change-Id: I57f56fbf4a8981d33b1571c0d93105cf8ca71d76
Reviewed-on: https://dart-review.googlesource.com/12260
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Before this change, each function and field had its own kernel data blob
in the VM heap. With this change, the entire kernel data of a library is
stored as one single blob in the VM heap. Functions and fields store an
offset which points to the kernel data, specific to them, in that single
blob.
The pointer to the kernel data for a library is saved in two places:
1. With the library objects themselves.
2. With all the patch classes of the library.
3. With the patch classes created during hot reload.
Change-Id: Ie03e738c4d20f16056a5ef04341b75506fda9c60
Bug:
Reviewed-on: https://dart-review.googlesource.com/6601
Commit-Queue: Siva Chandra <sivachandra@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
- 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>
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>
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>
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 .
This CL enables snapshotting for kernel.
Basically what it does is that it writes out and reads in a few
previously missing entries in the snapshot file (from Field, Function
and Script).
Debugging from a snapshot made from kernel will not work as snapshots
does not contain sourcecode (it is normally synthesized from the
TokenStream which doesn't exist in kernel).
BUG=
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2993613002 .
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 .
before reporting a path that goes through VM objects.
When a user attempts to check the retaining path of an instance of a
class, previously Observatory would report the first path found, even
if the path contains multiple VM objects.
Now, Observatory will attempt to find a path through the user fields and
ignores all VM objects aside from said fields. If that fails, it
defaults to the original algorithm.
BUG=
R=asiva@google.com, cbernaschina@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/2990643002 .
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 .
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 .
Modifies the debug garbage collector (CollectAllGarbage()) to correctly
remove inter-generational garbage by evacuating all of new space.
Adds tests to check if this issue has been correctly resolved.
Updates the WeakProperty_PreserveCrossGen test to call for one new and
one old space collection instead of CollectAllGarbage(). Otherwise, all
weak properties are swept as garbage.
DETAILS:
ISSUE
Specifically, the following arrangements in a heap resulted
in garbage surviving a GC.
- Dead object in old space pointing to dead object in new space results
in the new space object surviving.
- A cycle between two dead objects, one in each space, results in the
cycle surviving until all objects are in the old space.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2964503005 .
Adds tests to check if this issue has been correctly resolved.
Updates the WeakProperty_PreserveCrossGen test to call for one new and one old space collection instead of CollectAllGarbage(). Otherwise, all weak properties are swept as garbage.
DETAILS:
ISSUE
Specifically, the following arrangements in a heap resulted
in garbage surviving a GC.
- Dead object in old space pointing to dead object in new space results
in the new space object surviving.
- A cycle between two dead objects, one in each space, results in the
cycle surviving until all objects are in the old space.
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2930943002 .
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 .
I collected statistics for the sizes and capacities of growable arrays which are promoted to old-space or survive an old-space gc when running dart2js and Fasta. For these applications, the vast majority of arrays stay empty. More than half of the total object size of promoted backing arrays is backing for empty growable arrays.
Furthermore, since the overhead for an array is 3 words (header, type parameters and length), and object sizes are rounded up to an even number of words, we waste one word for all even-sized arrays.
This CL changes the growth strategy so that empty growable arrays are created with a shared, zero-sized array as backing, avoiding the allocation of a backing array if no elements are added. When the array needs to grow, it starts out at 3 and grows to double size plus one each time: 7, 15, 31, ...
A few places in the VM code need to handle these shared, zero-sized arrays specially. In particular, the Array::MakeArray function needs to allocate a new, empty array if its result is to be returned to Dart code.
Benchmarks suggest that the change improves memory usage by a few percent overall and does not significantly affect run time.
BUG=
R=erikcorry@google.com
Review-Url: https://codereview.chromium.org/2949803002 .
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 .
- Put pointer to kernel data into Script.
- Replace function.kernel_function pointer to AstNode with
kernel_offset():
- Replace field.kernel_field pointer to AstNode with kernel_offest().
- Stream the previously unstreamed AstNodes: FunctionDeclaration and
FunctionExpression.
- Move special handling for _buildin.getMainClosure into the streaming
flowgraph builder.
- Delete big parts of kernel_to_il.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2901533002 .
Only include OSR and field guards in the features descriptor for JIT code to avoid gen_snapshot and dart having different default values.
Disabled since core snapshots with code break tests with non-default flags for type checks, assertions, strict errors, OSR, or field guards.
R=zra@google.com
Review-Url: https://codereview.chromium.org/2902313004 .
Used for the visitors in the scavenger and marker. Each of these seems to give a few percent speed improvement for new and old space collections, respectively.
Around 0.1% total VM size increase (on ARM64).
R=erikcorry@google.com
BUG=
Review-Url: https://codereview.chromium.org/2908353002 .
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 .
Siva Chandra