Hey gym,
1) You don't have to go that far. No need to close or reset anything,
simply run the app from within the emulator (obviously, you need to
update it via adb install -r or something if you changed it). It will
show up in the process list in the DDMS, but you'll see that it
doesn't have that cute bug next to it. You can still add the heap
watch to it, this will not affect anything. And you can always attach
the debugger later if you need to debug something -- if you have the
heap watch on too, you might be able to see a change in behavior as
soon as you attach it. In my test app that repeatedly called
BitmapFactory.decodeFile and/or threw an exception, I noticed an
immediate continual increase in memory usage until it OOMed.
2) You won't necessarily see any garbage collection until the VM
decides to collect. That's okay. It doesn't matter if your app takes
up 15MB without ever collecting garbage. But as soon as you do an
allocation that exceeds the amount of available RAM, the gc should
kick in and take out the trash. Basically, it's all good as long as
you don't OOM. If you OOM, something went wrong.
Please note the very beginning of this thread - there is a known
problem in the Gallery class, it never recycles its views. However, I
have an app that uses two Galleries, both of them using
BitmapFactory.decodeFile(). I've run it on my device, sometimes with
1000 entries in the Gallery and scrolling like crazy, and I've never
OOMed. If I have the debugger attached, I OOM pretty quickly.
3) Interesting. SHOULDN'T happen, the VM should automatically gc as
soon as you're running out of memory.
Are you doing anything funky with your Bitmap/Drawable objects? How do
you manage them?
On Jan 17, 9:03 am, gymshoe <gyms...@bresnan.net> wrote:
> 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 <fad...@android.com> wrote:
>
> > On Jan 9, 4:47 pm, Mark K <mark.ka...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
