| e928a238e5e7f7b9fd74ed460f7e7943484d96af |
|
12-Sep-2014 |
Mathieu Chartier <mathieuc@google.com> |
Fix race between finalizeAllEnqueued and GC
Problem: GC uses pendingNext field for its internal references. This
causes a race where the GC can see the sentinel finalizer reference
through the internal doubly linked list and scan it before the
referent is marked, resulting in the pendingNext being part of a GC
internal reference queue. Then when we updated the pendingNext to
make a circular list it broke the list since the node never reached
the head.
The solution is to use native code so that we can use the same lock
that the GC uses when enqueing references and retry if the GC
changed the pendingNext.
Bug: 17462553
Change-Id: I0388f289a83d9b48e88129fe5b4b49ace4c5a1ca
|
| 2cc3d41ff2dfd673fa1ab4ef2a46525933d523ec |
|
04-Sep-2014 |
Mathieu Chartier <mathieuc@google.com> |
Fix race in finalizeAllEnqueued.
The problem was as follows:
The GC finishes and enqueues all cleared references on the
ReferenceQueue.unenqueued list. Then someone calls
finalizeAllEnqueued which enqueues a finalizer reference directly on
the finalizer reference queue. However the recently cleared references
had not yet been processed by the ReferenceQueueDaemon resulting
in the sentinal being finalized before the objects which were freed
in the GC.
The fix is enqueuing the sentinel finalizer reference on the unenqueued
queue.
Bug: 17371542
Bug: 17381967
Change-Id: I0455c665558397b70a88a97c59fe50090fa57401
|
| 2680db46e43b69cc1c49429d371cd1c7512d6f2c |
|
01-Aug-2012 |
Elliott Hughes <enh@google.com> |
Clean up lint in java.lang.ref.
Change-Id: Ie54af5965f07e8f0261eaeb5803d718658da2a23
|
| 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
|
| 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
|
| 7796ec1e199a9d4f791ae206a60e35fd82d2b462 |
|
11-Jun-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix ReferenceQueue linked list manipulations.
This change fixes a bug where the linked list would be truncated
whenever the head element was removed.
Change-Id: I81dbc963794feb40215ae287449c97acf3fe7050
|
| 55d86d85b3cd11461ba793cdc8ed74c87311a447 |
|
31-Mar-2011 |
Carl Shapiro <cshapiro@google.com> |
Implement reference queuing in managed code.
This change adds a thread to the core library which receives a list of
references after a garbage collection and enqueues each element. This
list is constructed by linking together the pendingNext field of cleared
references into a circular queue.
To support this change, the pendingNext field has been replaced by the
new zombie field for the purposes of providing a strongly reachable
location within a FinalizerReference class instance.
Change-Id: Id09133e44c850797e7f14c5471123a036d027c80
|
| 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
|
| bbfadc8ae01454abba5335fccceaa1c80123ae49 |
|
21-Mar-2011 |
Carl Shapiro <cshapiro@google.com> |
Move finalization into the core library.
Change-Id: I969ecc25f2a7e655e1093855514102662846dfe1
|