| fa5b565a3f6c6d7cbd6106ee8d360304c3a939a3 |
|
17-Feb-2017 |
Igor Murashkin <iam@google.com> |
jni: Switch to @FastNative for all JNI functions.
Switches all (248) methods that previously used !bang JNI in art/libcore
to all use @FastNative.
As a nice benefit, this should be about 1.5x faster than before for those method calls.
This measures out to a 3% startup time improvement for system_server.
Test: make test-art-host
Bug: 34955272
Change-Id: I0881f401c7660c79f275235362777bfa58241deb
|
| b6ae6ab47b47289f61dfa583832a1e3662dc99a5 |
|
14-Dec-2016 |
Mathieu Chartier <mathieuc@google.com> |
Fix accidental calling of wrong clear()
Use clearReferent instead of FinalizerReference.clear.
Test: test-art-host ART_TEST_INTERPRETER=true ART_TEST_READ_BARRIER=true
Change-Id: I57fc1f46c8c3c2b6d35741ab8549020894de7026
|
| 1b322dad1a0417190ca27bacf796252f95bf67ad |
|
13-Dec-2016 |
Mathieu Chartier <mathieuc@google.com> |
Move java.lang.ref.Reference.clear() to native
Required for adding exclusion for Reference.clear and reference
processing.
See accompanying change:
https://android-review.googlesource.com/#/c/313664/
Bug: 33389022
Test: test-art-host
Change-Id: Iee83b76d84453e929172f1a83f284aa4910e126c
|
| e81e4fadcf95fdbd697ea91cf953470a495a3891 |
|
02-Dec-2016 |
Hiroshi Yamauchi <yamauchi@google.com> |
Use getReferent() in enqueueSentinelReference to avoid race with GC.
This is the libcore part.
Fix a check failure due to the direct referent access that races with
the GC reference processing for CC.
Bug: 33207594
Bug: 12687968
Test: test-art-host with and without CC.
Change-Id: Ie1bda6e2fcafed2e6806e9244a7baa69d62022ad
|
| 9b2d8e2e2f3b453ba0e51473a2fbf150d8446670 |
|
05-Jun-2015 |
Mathieu Chartier <mathieuc@google.com> |
Add VMRuntime.runFinalizationWithTimeout
Used by native allocations to prevent deadlocks.
(cherry picked from commit 51855ccb72d01a28babedbaed70974d4f3697ab0)
Bug: 21544853
Change-Id: I57b2f7ae8b74185922eb3c15ba0ab71a4d2348aa
|
| 51855ccb72d01a28babedbaed70974d4f3697ab0 |
|
05-Jun-2015 |
Mathieu Chartier <mathieuc@google.com> |
Add VMRuntime.runFinalizationWithTimeout
Used by native allocations to prevent deadlocks.
Bug: 21544853
Change-Id: I57b2f7ae8b74185922eb3c15ba0ab71a4d2348aa
|
| 4c1daa0bba8fdd583581bdcd6ceb423631172f71 |
|
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
(cherry picked from commit e928a238e5e7f7b9fd74ed460f7e7943484d96af)
Change-Id: I6b68ca210bdda3c2468c5519d423f0bb1f00fc14
|
| 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
|
| de49a22034cfb5b50467cde52cdcb268d6b7423a |
|
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.
(cherry picked from commit 2cc3d41ff2dfd673fa1ab4ef2a46525933d523ec)
Change-Id: I0598199ef56aa8bd9e1fa40c39d50b2785dc5c10
|
| 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
|