- 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>
* Use 3-arg variant of open() to fix compilation on GCC and also to ensure
that created file is readable/writable by all users.
* Avoid changing protection on code pages emitted into VM isolate heap: this
allows to profile stubs.
Change-Id: I2b621596405ad78f54a63cfebde7a1af9fa15911
Reviewed-on: https://dart-review.googlesource.com/57263
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@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>
The compactor copies all live objects in old space to fresh pages, places forwarding pointers in the old objects, forwards all the pointers, then frees the old pages. This has a high space overhead. It is not meant for use in production, but meant to test that the VM is properly set up to handle old-space objects moving.
Large page objects and instruction objects are not moved.
Bug: https://github.com/dart-lang/sdk/issues/30978
Change-Id: Ia42683fd5e27a33702aa5e83bece803a8b005a4b
Reviewed-on: https://dart-review.googlesource.com/13624
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Erik Corry <erikcorry@google.com>
Estimate the speed of mark-sweep (or just marking if concurrent sweep is enabled) and use it to decide if a mark-sweep would complete within an idle period.
Start considering idle mark-sweeps when old-space has grown half way to the size that will trigger a blocking GC.
Change-Id: Id03e443365c2f965b41cbc1b7787916edbe7f48f
Reviewed-on: https://dart-review.googlesource.com/3423
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This version of the Timeline allows the developer to see a logical
view over the operations involved in each frame.
Events are grouped by frame and shifted accordingly to avoid to have
overlapped frame.
See runtime/observatory/web/timeline.js for the undestrand the steps
involded in the process.
Change-Id: I3980a3278a32fe69ed70db07cfa7189dc0c9a643
Reviewed-on: https://dart-review.googlesource.com/5603
Commit-Queue: Carlo Bernaschina <cbernaschina@google.com>
Reviewed-by: Todd Turnidge <turnidge@google.com>
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 .
At the moment isolated has a name field which is on the main_port the
only exception is the vm-service isolate.
The name is used just for logging.
The service protocol though uses an extra field called debugger_name,
that at this moment is redundant and is optimized away during
compilation.
BUG=
R=rmacnak@google.com, zra@google.com
This CL:
- Removes the debugger_name in favor of a modifiable name
- Adds to all the log where the name was logged the main_port (that is
the only real identifier)
- Changes the default format of the isolate name from:
<script_uri>$<main>
to:
<script_uri>:<main>()
Review-Url: https://codereview.chromium.org/3004563003 .
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 .
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 .
Ryan Macnak