| 161ab7af0434978ad3a9512293a032861a18e16e |
|
02-Dec-2015 |
Mathieu Chartier <mathieuc@google.com> |
Change FinalizeTest to use helper function
Old way kept the object live in a vreg.
Bug: 25851249
(cherry picked from commit cf3d432790a78b7d81da656f9a666f3d1ce4962c)
Change-Id: I3cefd317e23c602c6c74dd866f0831161ef10962
(cherry picked from commit 8210c23a598b363e89d6cd32dedeeae673bf9212)
|
| 8210c23a598b363e89d6cd32dedeeae673bf9212 |
|
02-Dec-2015 |
Mathieu Chartier <mathieuc@google.com> |
Change FinalizeTest to use helper function
Old way kept the object live in a vreg.
Bug: 25851249
(cherry picked from commit cf3d432790a78b7d81da656f9a666f3d1ce4962c)
Change-Id: I3cefd317e23c602c6c74dd866f0831161ef10962
|
| cf3d432790a78b7d81da656f9a666f3d1ce4962c |
|
02-Dec-2015 |
Mathieu Chartier <mathieuc@google.com> |
Change FinalizeTest to use helper function
Old way kept the object live in a vreg.
Bug: 25851249
Change-Id: I0027d86ea1a6964bee43fde958b68fe4d21cb0ff
|
| 3edd28a92fc86a1260347d0995e65a815d73bbbe |
|
16-Apr-2012 |
Mattias Petersson <mattias.petersson@sonymobile.com> |
Fix problem with Runtime.runFinalization()
This is a fix for a problem with runFinalization(). The
problem was that all FinalizerReferences to objects that had
not yet been garbage collected were lost when calling this
function. When a FinalizerReference was lost, it is was not
possible to call the finalize() method when the object
was garbage collected.
The result was that finalizers was sometimes never
called, which typically lead to memory leaks.
Also stop synchronizing on the class itself; use a private
lock instead.
Bug: 6907299
Bug: 5462944 # Synchronization on FinalizerReference.class
Change-Id: Ief515edbb5a1823c06d7371415d131165baef7f2
|
| 1a9cff8f68deffd618c5cba1f22f0fb0e396e067 |
|
17-Nov-2011 |
Jesse Wilson <jessewilson@google.com> |
Always trigger finalization the same way in our tests.
This came up when I was recently writing a ZipFile finalization test
and I needed to copy-paste the finalizer recipe.
Change-Id: Ia67061b3dba1a7011c93c9a81e2a963876b238a1
|
| 29e0638aca737dd1093dac55216982b5af7d59a7 |
|
12-Aug-2011 |
Jesse Wilson <jessewilson@google.com> |
Scrub some CTS test failures.
Change-Id: Icc35a44bac6481b549a96d0533770d11aff507da
|
| 9429d06c5427a6cac499ba90f138afac006135a2 |
|
21-Jun-2011 |
Jesse Wilson <jessewilson@google.com> |
Fix System.runFinalization() to avoid running indefinitely.
This also avoids problems where System.runFinalization() calls
Thread.interrupt() and interrupts a finalizer that is doing
some I/O.
Change-Id: I8de88d7382f684798737ecd19b90d306d9590f1c
http://b/4193517
|
| 64c6c367497c7fcf88e7527022234043e4460758 |
|
21-Jun-2011 |
Jesse Wilson <jessewilson@google.com> |
Implement the finalizer watchdog.
Change-Id: Ia4aaf5f0ef5a2f5f7e6ec3e8b4c4e300c9e1b2ee
http://b/4144865
|
| 6a22fa91a64739523c1344023f6dfde57e53110e |
|
31-Mar-2011 |
Jesse Wilson <jessewilson@google.com> |
Fix race conditions in finalizers.
We had several small races:
- runFinalization() could return before all objects had been
finalized
- stopFinalizer() could return before the thread was stopped
We still have one scenario where runFinalization returns
prematurely, this is due to a timing issue with the native
heap worker thread.
Change-Id: I304e4f2d744ed714a5c2069f2749df2ec1f40cc8
http://b/4192343
|