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>
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>
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 .
The decision to grow is based on the fraction of the objects that became garbage in the previous scavenge. If the previous scavenge included a growth, the new size of new space does not affect this statistic. If the program's allocation pattern remains the same, the next scavenge will see the same garbage ratio and decide to grow again, even if we would have hit the desired garbage fraction at the current capacity. This CL changes the garbage fraction to use the post-growth capcity as the dominator to prevent this eager double-growth.
This change causes Flutter Gallery to stablize at a 4MB semispace instead of 16MB, with ~10ms instead of ~40ms scavenges while interacting with the time picker on a Nexus 4.
R=danunez@google.com
Review-Url: https://codereview.chromium.org/3003063002 .
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 .
The IO tests unscheduled the mutator thread constantly, forcing the
isolate to fill new space and cause a GC.
Now, the mutator thread keeps its TLAB when unscheduled, taking
advantage of the fact the same thread object will always be the
mutator thread.
R=asiva@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/2993863002 .
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 .
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 .
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 .
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 .
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 .
- use attribute 'no msan' on NativeEntry::ReturnValueIsError function
as msan doesn't seem to track the return slot being set by a native
function
- vsnprintf seems to have issues with msan so unpoison the allocated
memory buffer everytime vsnprintf is used to suppress the error.
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2383293003 .
Martin Kustermann