Dianne - Thanks so much for the insight! That seems very much to be the case because if I force a GC through DDMS on the remote process, all those objects in the application process finally get released.
Something else I would recommend is to not do a design where you > instantiate Messenger objects for each IPC you do. Create one Messenger > that you pass in to each IPC call. Otherwise you can generate a lot of > remoted objects that are being kept around due to other processes > continuing to hold references because the other side is not aggressively > garbage collecting since all the objects it is creating due to these calls > are small. Your point is well taken about the design issue; this statement looks to describe my application exactly. The service has so few objects it rarely ever triggers GC, but it is in control of all the other objects in my application process. I will take a look at this and the workaround you proposed as well. Thanks again! Dave Smith @devunwired On Thursday, August 30, 2012 4:12:02 PM UTC-6, Dianne Hackborn wrote: > > It is true that sending a messenger across processes will require holding > a GREF on it for the other process to communicate with it. Barring bugs > (which have happened but I am not sure if in any released platform > versions), the GREF will be released when the other process itself no > longer holds a reference on this. When we are talking about things in > Dalvik "no longer holds a reference" generally means "the other side has > garbage collected the Java proxy object." > > What this means is that when you throw a Messenger (or any IBinder object) > across to another process, the Dalvik VM in your own process can no longer > manage the memory of that object itself and is dependent on all remote > objects releasing it until it can be released locally. And this will > include all objects that the IBinder has any references to as well. > > A common pattern to deal with this is to use a WeakReference in your > IBinder/Messenger that holds the references to the rest of your objects > that it will access. This allows your local garbage collector to clean up > all of those other objects (which may be quite heavy, holding big things > like bitmaps and such) even though a remote process still has a reference > on your IBinder. Of course if you do this, there needs to be something > else holding a reference on these other objects until they are no longer > needed, or else the garbage collector could clean them up *before* they are > no longer needed. > > Something else I would recommend is to not do a design where you > instantiate Messenger objects for each IPC you do. Create one Messenger > that you pass in to each IPC call. Otherwise you can generate a lot of > remoted objects that are being kept around due to other processes > continuing to hold references because the other side is not aggressively > garbage collecting since all the objects it is creating due to these calls > are small. > > -- > Dianne Hackborn > Android framework engineer > hac...@android.com <javascript:> > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
