| 15328602ac817be9cf1fc476988394416e797876 |
|
06-Jan-2016 |
Richard Uhler <ruhler@google.com> |
Improve performance of Reference processing.
By using synchronization on the ReferenceQueue instead of volatile
modifiers, and adding internal support for ReferenceQueue batch
enqueue and remove.
ReferenceBenchmark improvements on hammerhead:
Alloc 250 => 150
AllocAndEnqueue 1060 => 612
AllocEnqueueAndPoll 1300 => 725
AllocEnqueueAndRemove 1350 => 812
AllocImplicitEnqueueAndRemove 7000 => 1758
Finalization 10000 => 6095
Bug: 24404957
Change-Id: I6c3e83f7c34f5c22b001e513b50c932a0d54fd43
|
| 075523f1b503b1c340ab5ab717d3c6b19d62a5fa |
|
24-Nov-2015 |
Narayan Kamath <narayan@google.com> |
Make uncaught exceptions from finalizers non-fatal.
This was an accidental change - we don't the platform's default
uncaught exception handler to handle these.
bug: 25838479
bug: 25846607
bug: 25860695
Change-Id: I452fb8e1362a06b6bd4efa8bfccd88088e93ceae
|
| 39aff9afae048de1a9dcc4a19b0e175bcbae8af5 |
|
24-Nov-2015 |
Narayan Kamath <narayan@google.com> |
Make uncaught exceptions from finalizers non-fatal.
This was an accidental change - we don't the platform's default
uncaught exception handler to handle these.
bug: 25838479
bug: 25846607
bug: 25860695
Change-Id: I452fb8e1362a06b6bd4efa8bfccd88088e93ceae
|
| 02821acabbe6d8f7bddfb8ac44e7f4d5a56431fe |
|
18-Nov-2015 |
Narayan Kamath <narayan@google.com> |
Report finalizer related exceptions consistently.
When finalizers time out, we first try and report exceptions to the
default uncaught exception handler. Do the same for finalizer exceptions
too. Partial fix for the bug below, to try and make the behaviour of
059-finalizer-throw and 030-bad-finalizer consistent across host and
target.
bug: 25759624
Change-Id: Ib053e29eaa2a9b815fc772f1faafe7624ec05d2c
|
| ad1629101546eb3b00c5674ec1d84a8e0df12ace |
|
06-May-2015 |
Piotr Jastrzebski <haaawk@google.com> |
Use OpenJdk implementation of java.lang.ref.*.
- Daemons: Use enqueue instead of enqueueInternal.
- Reference / ReferenceQueue : Modified to work with ART.
Change-Id: Ie23cf4828d298d5df880766945efb47333469fdb
|
| 0ea934f8b29fdfa94527e74a1680a4f8e785c002 |
|
10-Nov-2015 |
Hans Boehm <hboehm@google.com> |
Fix spurious finalizer timeouts on shutdown.
Also report slow finalizers correctly by tracking object, rather than
reference being finalized.
Bug: 25606036
Change-Id: Iabcb2c2fad76cded67f1eb337c1b45cb8632339a
|
| 97e6de184bab5099f7451214f22299e35c12c24d |
|
01-Oct-2015 |
Hans Boehm <hboehm@google.com> |
Speed up Finalizer Daemon
Finalization performance is occasionally performance critical.
Do as little per-object work in the finalizer as we possibly can.
This removes a per object lock acquisition, notify, and system
call (via JNI) to get the current time.
It also fixes a lost notify bug that could theoretically prevent
the last finalizer from ever timing out, and reduces the already
tiny chance of reporting the wrong object for a finalizer
timeout.
Minor disadvantages: A nonterminating finalizer can take twice
as long to time out. The code is even more subtle.
Add benchmark to measure timing impact.
This was measured to improve performance on the added benchmark
by somewhere around 2 or 3%, which is hardly impressive. But
we've discovered several otheri, probably more serious, performance
issues in this area, which should eventually make those 2 or 3% more
noticeable. And we have to start somewhere.
Bug: 24404957
Change-Id: I77cc1222752ad05caf90001126f3e9eb016b296e
|
| 6a82f1259e2e15e5d73ab1b3b790a563bd0c890e |
|
22-Sep-2015 |
Mathieu Chartier <mathieuc@google.com> |
Handle OutOfMemoryError from allocating InterruptedExceptions
There can be OOME that occur from allocating InterruptedExceptions
these can cause test failures since daemon threads may still be
running when the runtime is shutting down.
Bug: 18577101
Change-Id: I020f8c9d0f1489772724522ba748eae84f69b424
|
| c536fe2655e28fcf81f8f4864052568b5bb1f72a |
|
12-Jun-2015 |
Mathieu Chartier <mathieuc@google.com> |
Send SIGQUIT when finalizer times out
The motivation is to get a native stack trace of the thread if it
is stuck in native code when runing a finalizer. Idea from agampe.
(cherry picked from commit b9f954826c2e81667f5aa466aa3084f789c384fb)
Bug: 21060358
Change-Id: I370988e6a0067e1d407c21881c82e49b6adec050
|
| b9f954826c2e81667f5aa466aa3084f789c384fb |
|
12-Jun-2015 |
Mathieu Chartier <mathieuc@google.com> |
Send SIGQUIT when finalizer times out
The motivation is to get a native stack trace of the thread if it
is stuck in native code when runing a finalizer. Idea from agampe.
Bug: 21060358
Change-Id: I370988e6a0067e1d407c21881c82e49b6adec050
|
| 3009efd22d7e41fefb25f1a545348e6db84e2f23 |
|
04-Mar-2015 |
Andreas Gampe <agampe@google.com> |
Libcore: Remove unused constructor
Change-Id: I8ca3a450d458d7eba13d8eee1f58fa3d907139b3
|
| a92ad71a13dc2df8fdc8e6fba33d1221bcc8dafe |
|
03-Mar-2015 |
Andreas Gampe <agampe@google.com> |
Libcore: Use explicit names for Daemons
getSimpleName is an expensive operation that needs to check the
dex file. Avoid for the standard daemons.
Bug: 19498458
Change-Id: I034aceabc9358ac6277b3ff8182df5cde681e66f
|
| 152be540e335376f66ed662d8e63e601a09cb4b3 |
|
19-Dec-2014 |
Mathieu Chartier <mathieuc@google.com> |
Move heap trimming daemon and GC deamon into a single daemon
Bug: 18739541
Change-Id: Icf309cd8981372f24caa7c8b98a2e0591b1d90ea
|
| a57efa2083afd417b0850a0e2a904780c90e1e1d |
|
15-Dec-2014 |
Mathieu Chartier <mathieuc@google.com> |
Move GC daemon locking logic into heap
Fixes deadlock caused by acquirng the mutator lock while
synchronizing on the daemon thread.
Bug: 18739541
Change-Id: Ib3ac3788081d3d471195a6e3a8ed163237616a4f
|
| 41739784355530c8762c5b93228bbcf2f589188b |
|
13-Dec-2014 |
Mathieu Chartier <mathieuc@google.com> |
Only allow one requestGC at a time
Fixes possible deadlock caused by Thread.getAllStackTraces
Thread.getAllStackTraces suspends all of the threads. If one of
the threads is a thread which holds the GC daemon lock then we
may deadlock when we allocate the stack trace. This happens if we
get a concurrent GC request when we are allocating the stack trace
elements. To fix the deadlock we now only allow a single thread to
requestGC at the same time.
Credits: yamauchi, hboehm
Bug: 18661622
(cherry picked from commit c0b55b80df57b9f8c659a5af4525ceba271622b6)
Change-Id: Iba46cb9c6cd2503d7af3348b4478c8c53973b9ee
|
| c0b55b80df57b9f8c659a5af4525ceba271622b6 |
|
13-Dec-2014 |
Mathieu Chartier <mathieuc@google.com> |
Only allow one requestGC at a time
Fixes possible deadlock caused by Thread.getAllStackTraces
Thread.getAllStackTraces suspends all of the threads. If one of
the threads is a thread which holds the GC daemon lock then we
may deadlock when we allocate the stack trace. This happens if we
get a concurrent GC request when we are allocating the stack trace
elements. To fix the deadlock we now only allow a single thread to
requestGC at the same time.
Credits: yamauchi, hboehm
Bug: 18661622
Change-Id: Ia25598e5daa8ff2dc3aa976148d5ff6afa6960f0
|
| 13ee952b30fdd08b986eb51c07c152f1d0d8f790 |
|
23-Oct-2014 |
Mathieu Chartier <mathieuc@google.com> |
Only allow once GC request at a time.
There is no reason to allow multiple, allocating threads may have
multiple GC requests before the GC starts.
Bug: 17942071
Change-Id: If31afa51a4da95955d538d47397cd96177987bcb
(cherry picked from commit 71891f9da2fbcb865931da70ae759032e6698106)
|
| 81df4adad0094ee5d4d92d49fdce4e19d3ccea39 |
|
23-Oct-2014 |
Mathieu Chartier <mathieuc@google.com> |
Only allow once GC request at a time.
There is no reason to allow multiple, allocating threads may have
multiple GC requests before the GC starts.
Bug: 17942071
(cherry picked from commit 71891f9da2fbcb865931da70ae759032e6698106)
Change-Id: I5e2162373bcef1027eb71e5b1699186ff015f92d
|
| 71891f9da2fbcb865931da70ae759032e6698106 |
|
23-Oct-2014 |
Mathieu Chartier <mathieuc@google.com> |
Only allow once GC request at a time.
There is no reason to allow multiple, allocating threads may have
multiple GC requests before the GC starts.
Bug: 17942071
Change-Id: If31afa51a4da95955d538d47397cd96177987bcb
|
| a05e22948de8285f0157e318e9d06e562f4a9440 |
|
16-Oct-2014 |
Mathieu Chartier <mathieuc@google.com> |
Fix ReferenceQueueDaemon.enqueue to start at element 1 of the list
Previously we started at element 2 and had that element 1 was the
last one finalized. This caused System.runFinalzition to
occasionally finish before all of the objects were finalized.
Bug: 17932313
Change-Id: I410dc1ef97ecd30c35f0fc0c3fdfbcc9caa585dd
|
| 5467456d499d7f99c68252a7d72858d65608a190 |
|
24-Sep-2014 |
Anwar Ghuloum <anwarg@google.com> |
Revert "Timing hacks DO NOT MERGE"
This reverts commit 6d688b8bb051942cd3cdd5fc1e19f42c3049f8a1.
Change-Id: Ia4e1ebd0849f4c6b9958d7d78edcedd096042926
|
| fd8e1f6d0601cd025f7f9e4c605a396bbafe2a60 |
|
19-Sep-2014 |
Mathieu Chartier <mathieuc@google.com> |
Change FinalizerWatchdogDaemon to not hold objects live
Previously, waitForFinalization would hold whatever object was being
finalized live for MAX_FINALIZE_NANOS even though the finalizer on
this object was run much earlier. This caused a test to be flaky since
it was assuming that the JNI weak global reference of a recently
finalized object wouldn't be held live.
Bug: 17305633
(cherry picked from commit 6ba680664fa14a547543a8c63708543ea8072680)
Change-Id: Ide60db55190a3764c16e4919a7c71a113cbf3968
|
| 6ba680664fa14a547543a8c63708543ea8072680 |
|
19-Sep-2014 |
Mathieu Chartier <mathieuc@google.com> |
Change FinalizerWatchdogDaemon to not hold objects live
Previously, waitForFinalization would hold whatever object was being
finalized live for MAX_FINALIZE_NANOS even though the finalizer on
this object was run much earlier. This caused a test to be flaky since
it was assuming that the JNI weak global reference of a recently
finalized object wouldn't be held live.
Bug: 17305633
Change-Id: Idc6ec28c22f8d5dd8650c000b15d6fc50a732a08
|
| 6d688b8bb051942cd3cdd5fc1e19f42c3049f8a1 |
|
04-Sep-2014 |
Anwar Ghuloum <anwarg@google.com> |
Timing hacks DO NOT MERGE
Let's submit to see if any issues remain
Bug: 17310019
Change-Id: Ifef1b1645033adcf192d6ec9248456cae28cd09f
|
| 2cf03dc15c40b92634ff606694af5a6e9aa4db09 |
|
22-May-2013 |
Brian Carlstrom <bdc@google.com> |
Adding libart support to libcore
Change-Id: I86febf08eacf42bb4b2f06dbd51c5b2d5b25c9fb
|