| Age | Commit message (Collapse) | Author |
|---|
|
This should improve behavior if we are nearly out of memory, and
multiple threads detect this at roughly the same time. This seems
to be common if system server uses too much memory for some reason.
1) When calling WaitForGcToComplete without holding gc_complete_lock_
only wait for the current GC to complete. Do not wait until no GC
is running. This avoids repeated waits when an allocation could
actually succeed.
2) If we tried to run a GC, but another thread got in before us,
check if we can allocate anyway, rather than treating this as failure
and forcing a GC.
3) After we tried to run a last ditch "emergency" GC, also try to
allocate again if another thread intervened, rather than insisting
on doing our own. We still weakly insist on doing our own before
throwing OOME, since we don't know if the other intervening GC
cleared soft references, etc.
Moved a logging call out of WaitForGcToComplete, since it belongs
in the caller.
Better documented a couple of almost-incorrect WaitForGcToComplete()
calls.
Bug: 353333767
Test: testrunner.py --host -b --all-gc --all-debuggable
Change-Id: Ie6d8789a4ca94978029f4ddee1a8fc62ea2a0e80
|
|
We used to look if there's any app image, however this can return true
when a shared library has an app image.
Test: test.py
Bug: 330564006
Change-Id: I0aa68edb14491db2fad6ea1d1c1b40d6c28eccff
|
|
Bug: 260881207
Test: presubmit
Test: abtd app_compat_drm
Test: abtd app_compat_top_100
Test: abtd app_compat_banking
Change-Id: Ib074e7b5ab0725fea5640ed7deaac3452fc27864
|
|
The logic that determines whether or not to write a runtime image
relied on the compiler filter, but the compiler filter no longer changes
since r.android.com/2745733. This caused runtime images to be repeatedly
generated. This CL fixes it.
Bug: 260557058
Bug: 299720365
Bug: 299870503
Test: Presubmit
Change-Id: I9f33e9b315b2da086974e49d1069fc3877052b20
|
|
This could happen with semi-space GC.
Test: test.py
Bug: 282967538
Bug: 260557058
Change-Id: Ib87c7ddb6b2ffa42e60a43a513f804fe0a6da24a
|
|
If the runtime still has a startup linear alloc, and we're deleting
class loaders, we may have dangling references in the startup linear
alloc. For simplicity, delete the startup linear alloc if we delete
class loaders.
Test: test.py
Bug: 282967538
Bug: 260557058
Change-Id: Ieb65ab7c1d0c1965233ebfc9eeac3faa0715a9c0
|
|
Bug: 169680875
Test: mmm art
Change-Id: Ic0cc320891c42b07a2b5520a584d2b62052e7235
|
|
- No need to be in a GC critical section.
- Make sure the dex cache is in the expected state before registering
it.
Also remove now unused ScopedInterruptibleGCCriticalSection
Test: test.py
Change-Id: I27b1209c7a21b811f9e17677e5e2bf70456aad8c
|
|
Boot image classes can be redefined, so we should not generate
an image.
Test: test.py
Bug: 276611504
Change-Id: Ia48297ef9be137068225e801d6a33abca603c38f
|
|
Address the long-standing TODO that this should be done outside of the
profiler. Also:
- Remove the need to check if the profile saver is started to allocate
full dex cache array. Now the notification that startup has completed
will always be sent
- Fix 1002-notify-startup test by creating the class loader hierarching,
making app image loading possible, which was the intention of the
code.
- Rewrite 1002-notify-startup to wait for the runtime to say startup has
completed, given it's an async task now reporting it.
Test: 1002-notify-startup
Bug: 260557058
Change-Id: I1fc0fc6b99de798e69af6ac4d57e8235d22c72e3
|