>
> So how useful HPROF is? If it's impossible to tell if an object is
> sitting there because the VM hadn't gotten around collecting it yet or
> because it's being leaked, I'd say it's not very useful.
>
It is useful, just look at the GC roots of an object to know whether it will
be collected or
> If I am understanding you correctly, then, it is merely a matter of
> them not having been GC'd yet. Bear in mind that the Dalvik GC
> implementation does not try to reclaim all unreferenced objects in a
> single pass.
So how useful HPROF is? If it's impossible to tell if an object is
sitting t
Ivan,
Which Android version are testing this with?
Among the devices I own, 2.2 seems much more aggressive with GC than 2.1.
01.04.2011 0:20 пользователь "ivan" написал:
> Roman, can you recommend your preferred way for analyzing whether or
> not an object is being withheld from GC by another?
>
Roman, can you recommend your preferred way for analyzing whether or
not an object is being withheld from GC by another?
On Mar 31, 2:05 pm, Romain Guy wrote:
> I have seen many lists with images before. Again, I'd be happy to fix a
> possible issue but I would need a repro case and an explanatio
I have seen many lists with images before. Again, I'd be happy to fix a
possible issue but I would need a repro case and an explanation of what is
holding memory and how. I can certainly see views moved to the scrap heap
holding onto these large images, but the scrap heap is mostly filled when a
li
Yeah we have a unique setup. An e-reader that uses a listview to actually
scroll vertically instead of using the conventional gallery, with very high
resolution images. It doesn't surprise me that you have not seen this
before, its an unconventional way of using a listview and we are using very
h
Bitmaps are an entirely different problem. Android 3.0 improves bitmaps
memory management a lot by reducing the time it takes for them to be
reclaimed by the GC. A leak happens only if there's memory that never gets
reclaimed, which I believe is not the case here. I would again be happy to
track do
There is no need to do this whatsoever. And you cannot "recycle" Views
anyway, at most you can set all the references to null manually which will
not make much of a difference. The GC will eventually collect the ListView
instances.
On Thu, Mar 31, 2011 at 11:32 AM, Matthew Powers wrote:
> I have
Sorry I didn't explain myself fully. In our layout we have a listview with
rather large images. We have shown many times that the gc does not run
quick enough to clean up the images onDestroy, onConfigurationChange, etc
and are getting OOM exceptions. We have seen bitmaps getting stranded and
hav
I have played with this MANY times. The only solution I have seen is to
walkthetree in the listview and recycle your objects by hand
On Thu, Mar 31, 2011 at 2:08 PM, ivan wrote:
> Ok I just tested the api demo again.
>
> I went in and out of List1.java 15 times, and only saw 8 instances
> still
Ok I just tested the api demo again.
I went in and out of List1.java 15 times, and only saw 8 instances
still on the heap.
So, clearly "some" are being GC'd.
My question still remains... Why doesn't this happen with other views?
On Mar 31, 11:50 am, ivan wrote:
> So to reiterate ...
>
> I can
So to reiterate ...
I can see every instance of a ListView/ListActivity (ever created)
sitting around in memory, even though I force a GC in every call to
onDestroy().
... And this is the expected behavior, because the Dalvik GC will
"eventually" collect them.
Why isn't this the case with other v
On Thu, Mar 31, 2011 at 11:58 AM, ivan wrote:
> Incoming references and path to GC root show only the TmpTestActivity.
If I am understanding you correctly, then, it is merely a matter of
them not having been GC'd yet. Bear in mind that the Dalvik GC
implementation does not try to reclaim all unre
Incoming references and path to GC root show only the TmpTestActivity.
On Mar 30, 5:56 pm, Mark Murphy wrote:
> On Wed, Mar 30, 2011 at 7:45 PM, ivan wrote:
> > I just ran the ApiDemos app (from SDK 7) in a stand alone emulator.
>
> > I went to List1, then back, then to List2, then back, then ba
On Wed, Mar 30, 2011 at 7:45 PM, ivan wrote:
> I just ran the ApiDemos app (from SDK 7) in a stand alone emulator.
>
> I went to List1, then back, then to List2, then back, then back to
> List1, etc... then:
>
> 1.) I used "adb shell ps" to view the process id.
> 2.) I used "adb kill -10 " to kill
I just ran the ApiDemos app (from SDK 7) in a stand alone emulator.
I went to List1, then back, then to List2, then back, then back to
List1, etc... then:
1.) I used "adb shell ps" to view the process id.
2.) I used "adb kill -10 " to kill the process and dump an hprof
3.) I pulled the hprof from
When I use MAT to look at TmpTestActivity, I
1.) Open the OQL tab in MAT and type the following query "select *
from com..TmpTestActivity" and run the query
2.) I right click on one of the TmpTestActivity result rows and choose
"List Objecst -> with incoming references" ... the results of whi
What exactly is leaking? What is the chain of references causing the leak?
If what you are describing is true it would affect pretty much every Android
application, which seems unlikely.
On Wed, Mar 30, 2011 at 2:23 PM, Mark Murphy wrote:
> On Wed, Mar 30, 2011 at 5:14 PM, ivan wrote:
> > I'm us
On Wed, Mar 30, 2011 at 5:14 PM, ivan wrote:
> I'm using a deice.
You should be testing this on an emulator in addition to your device.
Your device may have its own set of bugs and (strangely enough) the
home screen can impact this sort of thing as well. For a problem like
this, the emulator will
I'm using a deice.
On Mar 30, 1:30 pm, Mark Murphy wrote:
> On Wed, Mar 30, 2011 at 3:28 PM, ivan wrote:
> > John, I've read your post about this ... I launched a non-debug
> > version through eclipse (i.e. ctrl + F11) and pulled a heap hprof file
> > showing the same memory leaks.
>
> > Am I mi
On Wed, Mar 30, 2011 at 3:28 PM, ivan wrote:
> John, I've read your post about this ... I launched a non-debug
> version through eclipse (i.e. ctrl + F11) and pulled a heap hprof file
> showing the same memory leaks.
>
> Am I missing a step? When I was running I could see the process in
> DDMS, b
John, I've read your post about this ... I launched a non-debug
version through eclipse (i.e. ctrl + F11) and pulled a heap hprof file
showing the same memory leaks.
Am I missing a step? When I was running I could see the process in
DDMS, but break points and stack info were not available -- so I
Kostya asked if you were running under the debugger. This is relevant
because previously I too had a memory leak involved with ListViews and
eventually discovered that it only happened if I was running under the
debugger. So if you are running under the debugger, you might check
it without the de
Also, I'm using Android SDK build 8 (2.2).
On Mar 30, 11:37 am, ivan wrote:
> In addition, I've read that the leak doesn't occur while the app is
> running in a non-debug session. This is not the case with my
> experiments. I see the leak regardless.
>
> On Mar 30, 11:28 am, ivan wrote:
>
> >
In addition, I've read that the leak doesn't occur while the app is
running in a non-debug session. This is not the case with my
experiments. I see the leak regardless.
On Mar 30, 11:28 am, ivan wrote:
> onDestory has been called every time, which I've tested with a break
> point .
>
> On Mar 3
Are you running the app in the debugger?
30.03.2011 21:28, ivan пишет:
onDestory has been called every time, which I've tested with a break
point .
On Mar 30, 11:23 am, Mark Murphy wrote:
On Wed, Mar 30, 2011 at 1:18 PM, ivan wrote:
I accidentally posted that last one before I was done.
I h
onDestory has been called every time, which I've tested with a break
point .
On Mar 30, 11:23 am, Mark Murphy wrote:
> On Wed, Mar 30, 2011 at 1:18 PM, ivan wrote:
> > I accidentally posted that last one before I was done.
>
> > I have read copious posts on this, but no solution. After using MA
Mark,
I accidentally posted this before I was done... please see my second
post with the same title and "II" appended.
Sorry about the confusion.
On Mar 30, 11:10 am, Mark Murphy wrote:
> On Wed, Mar 30, 2011 at 1:06 PM, ivan wrote:
> > I have read copious posts on this, but no solution. Afte
28 matches
Mail list logo