I have noted the following discrepancies compared to the descriptions
here, using a similar, simple application which uses Gallery, and
BitmapFactory:
1) EboMike, How exactly do I run the application "without a debugger
attached"? I assume that closing Eclipse entirely, and launching a
new emulator from a DOS prompt (without Eclispe running) would be the
equivalent of not having a debugger attached.
When I do this, I get the same memory leak problem as I always did...
2) When I have the DDMS attached and running, the heap size doesn't
show any garbage collection (see below) going on for my gallery
application (unless I click on "Cause GC")...
3) If I call System.GC() intermittently directly in my application
(calling this method alone, and not as part of a {gc() /
runFinalization() / gc()} sequence), this prevents OOM, and then I can
see the GC altering the heap size (in DDMS).
Jim
On Jan 9, 6:37 pm, fadden <[email protected]> wrote:
> On Jan 9, 4:47 pm, Mark K <[email protected]> wrote:
>
> > I've tried it with no de-bugger, on the emulator, and on actual G1
> > hardware, I can't seem to get rid of the problem entirely. I only
> > process and use one bitmap at a time, bitmaps are recycled after use,
> > and I invoke gc(). The Runtime free memory indicates that I always
> > have over 10 MB free, each bitmap is less than 3.5 MB, yet this
> > problem still ocurs intermittently.
>
> What does logcat show at the point of the failure? Should see some
> additional traffic, e.g.:
>
> 01-09 16:13:02.739 D/dalvikvm( 178): GC freed 494 objects / 31264
> bytes in 265ms
> 01-09 16:13:02.829 I/dalvikvm-heap( 178): Grow heap (frag case) to
> 4.558MB for 998301-byte allocation
> 01-09 16:13:03.039 D/dalvikvm( 178): GC freed 133 objects / 6192
> bytes in 196ms
>
> Bitmap allocations are done outside of the virtual heap, but are
> counted against it. This was done somewhat late in the game and not
> all of the tools will include the bitmap heap allocation numbers in
> with the actual virtual heap allocations. If you're getting an OOM
> you should see it bumping up against the 16MB limit in the logs.
>
> FWIW, the only thing worse than explicit calls to System.gc() is
> following those with explicit calls to System.runFinalization(), which
> in Dalvik will block until finalizers have completed. If your
> allocations are somehow outpacing the ability of the system to GC then
> finalize then GC again to free the finalized objects, you can stick a
> runFinalization() in between a pair of calls to gc(). However, if
> you're explicitly calling recycle(), this shouldn't do much since the
> bitmap storage should have been released.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
