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 .
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 .
2. Get rid of _getMainClosure()
3. Adjust the AOT compiler to ensure it retains the function associated with
the main closure without having to include '_getMainClosure()' in the list
of embedder specified entry points
4. Get rid of the hack in kernel reader to do a delayed patch of
'_getMainClosure()' in the builtin library.
BUG=
R=aam@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/2933603002 .
- 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 .
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 .
The canonical name table is copied into a typed data array in the VM's
heap. The encoding is the same as in the binary except that the
integer indexes are fixed-size.
Canonical names are now integer indexes instead of objects allocated
in the C++ heap.
BUG=
R=jensj@google.com, vegorov@google.com
Review-Url: https://codereview.chromium.org/2853423002 .
Copy the Kernel string offsets into a uint32 array in the VM's heap.
This avoids allocating small string objects with new and avoids having
a table of the canonical strings.
Instead of an offset and a size, strings are now represented as
indexes into the string table in the heap. The start offset of string
N is found at byte offset N*4 because it is a uint32, and the end
offset is found at byte offset (N+1)*4. The strings themselves are
just integer indexes instead of pointers.
In the stream flow graph builder, string access is all random access.
R=jensj@google.com, vegorov@google.com
Review-Url: https://codereview.chromium.org/2852943003 .
This is a reapplication of https://codereview.chromium.org/2809583002/
with a fix for the AOT case.
We have been using IC data for receiver type info in the
PolymorphicInstanceCallInstr. This is a data structure optimized for
access from hand-coded assembly stubs, and placed on the GC-ed heap,
which means it has to be accessed through handles. With this change we
move it to the zone memory, which means it can be freed without an
old-gen GC. As a side-effect the zone arrays use exponential growth for
amortized constant space allocation instead of growing by 1 for
quadratic allocation when we add classes, further reducing memory
pressure.
R=vegorov@google.com
BUG=
Review-Url: https://codereview.chromium.org/2842753002 .
This reverts commit 2135c8a90f.
This is a reland of https://codereview.chromium.org/2809583002/
Original text:
We have been using IC data for receiver type info in the
PolymorphicInstanceCallInstr. This is a data structure optimized for access
from hand-coded assembly stubs, and placed on the GC-ed heap, which means it
has to be accessed through handles. With this change we move it to the zone
memory, which means it can be freed without an old-gen GC. As a side-effect
the zone arrays use exponential growth for amortized constant space allocation
instead of growing by 1 for quadratic allocation when we add classes, further
reducing memory pressure.
R=vegorov@google.com
BUG=
Review-Url: https://codereview.chromium.org/2833333003 .
We have been using IC data for receiver type info in the PolymorphicInstanceCallInstr. This is a data structure optimized for access from hand-coded assembly stubs, and placed on the GC-ed heap, which means it has to be accessed through handles. With this change we move it to the zone memory, which means it can be freed without an old-gen GC. As a side-effect the zone arrays use exponential growth for amortized constant space allocation instead of growing by 1 for quadratic allocation when we add classes, further reducing memory pressure.
R=vegorov@google.com
BUG=29302
Review-Url: https://codereview.chromium.org/2809583002 .
- Instead of a pointer to new'd memory, Kernel strings now have an
offset from the start of the string data.
- When the streaming reader encounters the string data it records the
offset from the start of the binary. This offset is stored in the
Kernel Program and is used to compute the offset for strings.
- When a KernelReader is constructed, the string data is copied into a
Uint8 array in the VM's heap.
- A pointer to the string data is put into every Kernel script so it
can be used for constructing VM strings at compile time.
The source table does not use Kernel strings any more because those
strings are not found in the raw string data. Instead, the source
table uses new'd buffers for strings (but this will be cleaned up
separately).
R=jensj@google.com
Review-Url: https://codereview.chromium.org/2820363002 .
function cloning for mixins, signature building, etc...).
Rename --generic-method-semantics flag to --reify-generic-functions (still not
working and disabled by default).
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2835513002 .
Types generated via instantiation during run time type tests are allocated in
new space and it makes sense (in the case of function types) to also allocate
instantiated signatures in new space.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2821233005 .
- Don't remove entries from a library's dictionary while iterating over it.
- Remove library prefixes from library dictionaries.
- Compact library dictionaries after removing entries.
- Track snapshot references in debug mode and give a backtrace when unencountering an unexpected object.
- Verify removed libraries are not included in the snapshot by marking their top-level classes.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2823873003 .
Previously we were converting very polymorphic calls that always end up
in the same implementation into a check-class instruction and a (usually
inlined) direct call. This works well in artificial benchmarks like
the Megamorphic suite, but tends to cause repeated deopts on large real
programs like dart2js, where new classes arrive after a while, triggering
the check-class instruction to deopt. After a few deopts, the function
is no longer eligible for optimization, resulting in huge slowdowns.
Instead with this change we can switch to the normal machinery for polymorphic
calls with more than one target. This has the advantage that we use a
megamorphic stub call to catch rare classes, rather than deopting.
Dart2js is speeded up by a few percent on average and avoids the big
performance potholes described in https://github.com/dart-lang/sdk/issues/29302
Also reverts a less effective workaround for 29302.
R=vegorov@google.com
BUG=29302
Review-Url: https://codereview.chromium.org/2829603002 .
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 .
type itself gets instantiated.
Until now, the signature was kept unchanged and the instantiation was reflected
by the type arguments of the function type only. This delayed instantiation
would complicate the implementation of generic functions.
This cl actually removes type arguments for (non-typedef) function types. The
function type is now fully represented by the signature. When the function type
is instantiated, a new signature is allocated (instead of a new type argument
vector) to hold instantiated result type and formal parameter types.
The same applies in the case of typedef function types, however, the type
arguments of the typedef are kept as before. This allows for better printing
of typedef function types and for finalization of recursive type involving
typedefs as type arguments.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2793033005 .
This reverts commit 30a942f728.
Plus:
1. Fixes integer type propagation in the optimizer by introducing a _int64 marker interface
2. Fixes calculation of whether an instructions can deoptimize: This has to be stable so that
once determined that an instructions can't deoptimize, it will stay that way and not flip back
later in the optimization
3. Address comments to improve CompileType::CopyNonNullable()
R=vegorov@google.com
Review-Url: https://codereview.chromium.org/2772143002 .
AssertAssignableInstr::Canonicalize was too restrictive: it can instantiate the
type even if the instantiator is null.
Do not allocate empty TypeArguments handles, but use the common one instead.
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2759393005 .
Erik Corry