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 .
The current old-space allocation implementation performs a
linear search in a single (potentially *very long*) free list for
allocations > 2k.
This CL will change this behavior to limit the number of free list
entries traversed, falling back to allocate a new page if the maximum
number of steps was reached. The new page will be pushed onto the
front of the free list, therefore making new allocations go there
immediately.
For the new tests/standalone/fragmentation_test.dart we
- pay around 11-12% increase in memory
- to gain a 6x speedup (125x speedup with sweepers disabled)
I tried a much more complicated version that had power-of-two
buckets for freelist items > 2k. This turned out to regress
dart2js and splay for reasons that I could not determine. This
version is much simpler and fixes the issue as observed in the
bug.
Closes#29588R=kustermann@google.com
Review-Url: https://codereview.chromium.org/2872883003 .
This CL removes the use of STL map from freelist.cc by adding
MallocDirectChainedHashMap in hash_map.h and adding an iterator for
BaseDirectChainedHashMap there.
It also removes a use of STL map from hash_table.h that was dead code.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2083103002 .
With the upcoming deletion barrier, every update of a pointer field must know whether the previous value was a valid pointer.
Currently, we always use StorePointer/StoreSmi, both for initialization and updates.
Initialization, and thus the potential for overwriting garbage values, appears in three places:
1. Object::Allocate/Foo::New.
2. Creating isolate from full snapshot.
3. Allocation in generated code.
Case 1 already null-initializes all underlying memory.
Case 2 is addressed by this CL by exploiting that:
i) fresh pages are zero-filled by OS, and
ii) freelist headers use only even values.
Case 3 is remains a TODO for future CLs.
(An alternative solution for case 2 would have been to add an init_foo method for every set_foo called.)
R=iposva@google.com
Review URL: https://codereview.chromium.org//792163003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42584 260f80e4-7a28-3924-810f-c04153c831b5
Change executable pages to be read/execute but not writable by default.
All pages are made temporarily writable just before a full GC, because both
the mark and sweep phases write to the pages. When allocating in a page and
when patching code, the pages are made temporarily writable.
The order of allocation of Code and Instructions objects is changed so that
a GC will not occur after Instructions is allocated. (A full GC would
render the Instructions unwritable.) A scoped object is used to make memory
protection simpler.
Original CL: https://codereview.chromium.org/106593002/
I added a cc test that is expected to crash.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//136563002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32493 260f80e4-7a28-3924-810f-c04153c831b5
The scavenger now reports survival and promotion statistics.
The statistics for the large free list are now reported. Previously,
only information about the small free list was printed. Each report
indicates whether the data is from before or after a garbage collection,
each row of a report is preceded by the free list type (small or large),
and cumulative bytes are reported for the free list type.
Review URL: https://codereview.chromium.org//11416384
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@16074 260f80e4-7a28-3924-810f-c04153c831b5
This change improves the utilization of the smallest size classes on
benchmarks performing old space allocations including Splay, Box2D,
and Dart2JSCompileAll.
Initial measurements showed that free list allocation was slightly
slower than bump pointer allocation. Profiling identified that free
list allocation spent most of its time searching for a matching size
class. To eliminate this overhead, a bitmap index has been added
resulting in no appreciable difference in running time between either
method.
Review URL: https://chromiumcodereview.appspot.com//10807031
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@9773 260f80e4-7a28-3924-810f-c04153c831b5
Removed initializations of class_ field done in runtime and generated code on ia32/x64.
Changed forwarding address encoding used by scavenger: kFreeBit is now used to distinguish evacuated objects from not evacuated because scavenger will never encounter real FreeListElement.
Changed FreeListElement layout to match RawObject layout.
R=iposva@google.com
Review URL: https://chromiumcodereview.appspot.com//10521004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@8336 260f80e4-7a28-3924-810f-c04153c831b5
Ryan Macnak