- Track mark-compact as a GC type instead of a GC reason.
- Track external allocation as a GC reason.
Change-Id: Id79bf6a582109e3ebb97954822aefeffe68959e2
Reviewed-on: https://dart-review.googlesource.com/58002
Reviewed-by: Zach Anderson <zra@google.com>
Previously, GC would only be triggered by external allocations on
reaching a limit indicated by a flag. This limit was too large
and not set thoughtfully by anyone.
This CL triggers GC when external allocations in old gen grow
larger than some limit based on results of previous GC, similar
to how Dart heap growth triggers GC. GC is triggered for new gen
when external allocations reach 4x the current new gen
capacity.
FL-61
Change-Id: I1d4da467bc2aab64058f25296aefdd73eebc38e6
Reviewed-on: https://dart-review.googlesource.com/58100
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Previously there were places in the code where an API accepted a
`bool validate_frames` and call sites passed an enum value (which
implicitly got converted to a bool).
By changing the APIs to require an enum, the compiler will tell us if a
caller doesn't pass one.
Change-Id: I29fcd0b018e6cdd7e00b5bb03e83b9636d1345d4
Reviewed-on: https://dart-review.googlesource.com/57823
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Régis Crelier <regis@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>
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>
Expands the mechanism that moves token streams to the VM isolate to include instructions and code metadata.
Allow the isolate snapshot to reference Instructions in the VM isolate.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2909403002 .
Use the speed of previous scavenges to estimate the time required for the next scavenge. When we receive an initial notification, perform a scavenge if we have allocated enough and we estimate we can complete the scavenge before the deadline.
Expand the time recorded for a scavenge to include safepointing and iterating roots.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/3001423002 .
When top_ is required, we now search through all active threads and pull
the top_ furthest in the space.
When searching the space, we fills every thread's TLAB with a
FreeListElement. Note that future allocations can safely overwrite
them. We do NOT abandon the TLAB (i.e. set top_,end_ to 0) in these
cases.
Added notes to determing where to lock/unlock for threads
R=asiva@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/2992753002 .
Revert "Attempts to fix bugs introduced in 8b6fcf50e85d."
This reverts commit 7568e1f18e.
Revert "Changes calculation of Scavenger's UsedInWords"
This reverts commit 91470e7211.
Revert "Fixes the regression caused by 7568e1f18e."
This reverts commit 479db734e3.
BUG=
Review-Url: https://codereview.chromium.org/2998663002 .
This reverts commit bb6203dade and
adds changes FlushTLS.
Now, FlushTLS will fill the mutator thread's TLAB instead of
changing top_ in the Scavenger. This should prevent the assertion
(thread->end() == 0) || (thread->end() == top_)
in TryAllocateInTLAB in runtime/vm/scavenger.h due to a race on top_.
R=asiva@google.com, rmacnak@google.com, zra@google.com
Review-Url: https://codereview.chromium.org/2991343003 .
Revert "Changes new space allocation from simple bump pointer allocation from"
This reverts commit e6e378bb6e.
Revert "Fixes bug in calculation of memory used by new space"
This reverts commit 044f818f01.
BUG=
Review-Url: https://codereview.chromium.org/2992923002 .
mutator to thread local allocation buffer system used only by mutator.
The new allocation scheme is as follows:
- Mutator allocates an aligned buffer from the heap.
- For each object the mutator wishes to allocate
- If the object fits in the overall space of the bufffer,
bump allocate into the buffer.
- If the object is larger than the buffer overall, allocate into old
space.
- If the object is not larger than the buffer but cannot fit,
make the buffer iterable by GC and allocate a new buffer.
- If the mutator cannot get a new buffer, do a GC and try again.
- If the mutator still cannot get a new buffer, allocate the object
in old space.
- If the mutator does get a new buffer (before or after GC), allocate
the object into the buffer.
BUG=
R=asiva@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/2985863002 .
This is the first step to adding Thread Local Allocation Buffers to
the VM.
In this step, the mutator alone allocates to the new space, but keeps
track of the start and end of the space. This is akin to a single large
TLAB.
As a result, the generated code and the dbc simulator changed how they
allocate objects into the new space as well.
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2980033002 .
This is the first step to adding Thread Local Allocation Buffers to
the VM.
In this step, the mutator alone allocates to the new space, but keeps
track of the start and end of the space. This is akin to a single large
TLAB.
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2951333002 .
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 .
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 .
This CL assigns names to vmos formatted as "isolate space type" where
isolate is the name of the isolate, space is "oldspace" or "newspace",
and type is "code" or "data".
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2929203002 .
The Scavenge (young-gen) GCs on the main thread have to wait for other
threads to check in at a safe point. We were seeing big waits here, often
20ms, occasionally up to 180ms where the main thread is idling, waiting
for the optimizing compiler. By adding more safe points the wait is
reduced and is now rarely over 10ms, often under 1ms.
This also changes the --verbose-gc output to be better aligned with the
column headings, and to add the time needed to get to
the safe point to the output, eg:
[ GC(784211551): Scavenge(new space), 18, 2.209, 76.009, 32768, 0, 32768, 32768, 0, 0, 144912, 154425, 152064, 154880, 0, 0, 46.984, 2.752, 7.407, 18.657, 0.033, 5421, 0, 0, 0, ]
^^^^^^ Scavenge time ^^^^^^ safe point time.
R=vegorov@google.com
BUG=
Review-Url: https://codereview.chromium.org/2771013002 .
heap contains verification under it. This flag is turned on automatically
when verify_before_gc, verify_after_gc or verify_on_transition is
specified. This should speed up the debug builds on the bot.
A dart2js build line for instance goes from 2357.526 seconds
to 184.22 seconds
2. Verify heap on shutdown only under the flag verify_on_transition.
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2626343002 .
i.e. #ifndef VM_WHATEVER -> #ifndef RUNTIME_VM_WHATEVER
This lets us remove a hack from the PRESUBMIT.py script that existed
for reasons that are no longer valid, and sets us up to add some
presubmit checks for the GN build.
R=asiva@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/2450713004 .
Prevents a race between the marker and finalizer when the handle is freed (fixes#27029).
Disallow creating weak handles for immediate objects. We don't distinguish these from free handles, so their callbacks are never run.
Don't report freed handles over the vm service.
R=asiva@google.com
Review URL: https://codereview.chromium.org/2281193002 .
Ryan Macnak