Hello. I tried posting this earlier, but it didn't seem to stick (so
sorry if it double posts).
My app occasionally runs out of memory when loading bitmaps. I call
recycle() on every bitmap I'm done with and even set them to null.
As far as diagnostics:
* I ran ddms and never saw the heap go over 5.5mb. The largest image I
load is 480x320, so there's no way that pushing it over the 16mb
limit.
* I dumped the event log and noticed this at one point:
I/dvm_gc_info( 6655):
[7290888427799873005,-9036888781628737488,-3939943202692585437,9505022]
According to somebody else's post this could be bad (sorry I lost the
link to that post). (gdb) print (0xtop12 & 0x1ff) << ((0xbottom12 >>
9) * 4) ==> resulting in greater than 17mb
* to confirm this, I dump hprof and analyzed it with Eclipse Mat, but
all I saw was a peak usage of 2.1mb and a suspected leak of 700k
* Scouring the forums, I found this:
http://groups.google.com/group/android-developers/browse_thread/threa... Could my problem really be due to memory fragmentation? My app does
load and unload(recycle) bitmaps often.
I don't know which of these to believe and what to do to prevent these
out of memory exceptions from ever happening again - or at the very
least I'd like to properly interpret the data I'm getting from these
logs and profilers.
> Hello. I tried posting this earlier, but it didn't seem to stick (so
> sorry if it double posts).
> My app occasionally runs out of memory when loading bitmaps. I call
> recycle() on every bitmap I'm done with and even set them to null.
> As far as diagnostics:
> * I ran ddms and never saw the heap go over 5.5mb. The largest image I
> load is 480x320, so there's no way that pushing it over the 16mb
> limit.
> * I dumped the event log and noticed this at one point:
> I/dvm_gc_info( 6655):
> [7290888427799873005,-9036888781628737488,-3939943202692585437,9505022]
> According to somebody else's post this could be bad (sorry I lost the
> link to that post). (gdb) print (0xtop12 & 0x1ff) << ((0xbottom12 >>
> 9) * 4) ==> resulting in greater than 17mb
> * to confirm this, I dump hprof and analyzed it with Eclipse Mat, but
> all I saw was a peak usage of 2.1mb and a suspected leak of 700k
> * Scouring the forums, I found this:http://groups.google.com/group/android-developers/browse_thread/threa...
> Could my problem really be due to memory fragmentation? My app does
> load and unload(recycle) bitmaps often.
> I don't know which of these to believe and what to do to prevent these
> out of memory exceptions from ever happening again - or at the very
> least I'd like to properly interpret the data I'm getting from these
> logs and profilers.
Memory fragmentation does not cause this; the Dalvik heap limit is enforced based on the actual active allocations.
Note that bitmaps are NOT include in the Dalvik heap based on what ddms reports, but they are included in the heap limit, so most likely you have a lot of bitmap data.
(In HC this is changed and bitmap data is now allocated directly on the Dalvik heap.)
On Thu, Feb 24, 2011 at 12:42 PM, Sheado <chad...@gmail.com> wrote: > Hello. I tried posting this earlier, but it didn't seem to stick (so > sorry if it double posts).
> My app occasionally runs out of memory when loading bitmaps. I call > recycle() on every bitmap I'm done with and even set them to null.
> As far as diagnostics: > * I ran ddms and never saw the heap go over 5.5mb. The largest image I > load is 480x320, so there's no way that pushing it over the 16mb > limit. > * I dumped the event log and noticed this at one point: > I/dvm_gc_info( 6655): > [7290888427799873005,-9036888781628737488,-3939943202692585437,9505022] > According to somebody else's post this could be bad (sorry I lost the > link to that post). (gdb) print (0xtop12 & 0x1ff) << ((0xbottom12 >> > 9) * 4) ==> resulting in greater than 17mb > * to confirm this, I dump hprof and analyzed it with Eclipse Mat, but > all I saw was a peak usage of 2.1mb and a suspected leak of 700k > * Scouring the forums, I found this:
> I don't know which of these to believe and what to do to prevent these > out of memory exceptions from ever happening again - or at the very > least I'd like to properly interpret the data I'm getting from these > logs and profilers.
> any advice would be awesome! > thanks.
> -- > 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
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.
android777 - Unfortunately it's a lot of code, but I pretty much just
load my bitmaps, and later on just call .recycle() on them. It's
possible there's a bug and some of the .recycle() calls aren't being
reached and I'm having a hard time tracking them down using profiling
tools.
Dianne - that explains a lot, thank you. Is there any way to get an
accurate (bitmap included) picture of the heap in pre-honeycomb builds
of an app?
On Feb 25, 9:14 am, Dianne Hackborn <hack...@android.com> wrote:
> Memory fragmentation does not cause this; the Dalvik heap limit is enforced
> based on the actual active allocations.
> Note that bitmaps are NOT include in the Dalvik heap based on what ddms
> reports, but they are included in the heap limit, so most likely you have a
> lot of bitmap data.
> (In HC this is changed and bitmap data is now allocated directly on the
> Dalvik heap.)
> On Thu, Feb 24, 2011 at 12:42 PM, Sheado <chad...@gmail.com> wrote:
> > Hello. I tried posting this earlier, but it didn't seem to stick (so
> > sorry if it double posts).
> > My app occasionally runs out of memory when loading bitmaps. I call
> > recycle() on every bitmap I'm done with and even set them to null.
> > As far as diagnostics:
> > * I ran ddms and never saw the heap go over 5.5mb. The largest image I
> > load is 480x320, so there's no way that pushing it over the 16mb
> > limit.
> > * I dumped the event log and noticed this at one point:
> > I/dvm_gc_info( 6655):
> > [7290888427799873005,-9036888781628737488,-3939943202692585437,9505022]
> > According to somebody else's post this could be bad (sorry I lost the
> > link to that post). (gdb) print (0xtop12 & 0x1ff) << ((0xbottom12 >>
> > 9) * 4) ==> resulting in greater than 17mb
> > * to confirm this, I dump hprof and analyzed it with Eclipse Mat, but
> > all I saw was a peak usage of 2.1mb and a suspected leak of 700k
> > * Scouring the forums, I found this:
> > I don't know which of these to believe and what to do to prevent these
> > out of memory exceptions from ever happening again - or at the very
> > least I'd like to properly interpret the data I'm getting from these
> > logs and profilers.
> > any advice would be awesome!
> > thanks.
> > --
> > 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+unsubscribe@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
> 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.
In summary, the issue is that bitmap memory takes several GC passes to deallocate, so it's really easy to get ahead of the GC and run out of memory.
AFAIK, there's no fix. You can help the situation somewhat by calling System.gc() after every Bitmap.recycle() call, and again before every bitmap allocation. But that's only somewhat. I've also found that setting bitmap variables to null after recycling them makes matters worse, but YMMV.
Thanks for that link String. I'll look into calling System.gc() - I've always thought (and read posts warning against it) it was bad practice to do so on Android. But I'll do it anyway if it fixes my problem =]
-Sheado
On Fri, Feb 25, 2011 at 3:07 PM, String <sterling.ud...@googlemail.com>wrote:
> In summary, the issue is that bitmap memory takes several GC passes to > deallocate, so it's really easy to get ahead of the GC and run out of > memory.
> AFAIK, there's no fix. You can help the situation somewhat by calling > System.gc() after every Bitmap.recycle() call, and again before every bitmap > allocation. But that's only somewhat. I've also found that setting bitmap > variables to null after recycling them makes matters worse, but YMMV.
> String
> -- > 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
It is also interesting to notice: according to the official
documentation for Android Java at developer.android.com, System.gc()
is only a hint; it is no guarantee that garbage collection will
actually take place.
That said, people have told me that the hint is usually taken.
On Feb 25, 3:07 pm, String <sterling.ud...@googlemail.com> wrote:
> In summary, the issue is that bitmap memory takes several GC passes to deallocate, so it's really easy to get ahead of the GC and run out of memory.
> AFAIK, there's no fix. You can help the situation somewhat by calling System.gc() after every Bitmap.recycle() call, and again before every bitmap allocation. But that's only somewhat. I've also found that setting bitmap variables to null after recycling them makes matters worse, but YMMV.
I have an even more frustrating version of that bug. We use a mapview
that supports rotation and thus is slightly larger than the screen
area. When users zoom in a few times they can very easily cause the
OOM condition. I have no control over the way the Google Maps API
works, do I?
By the way, OOM is catchable. Not that it would help much though...
> In summary, the issue is that bitmap memory takes several GC passes to deallocate, so it's really easy to get ahead of the GC and run out of memory.
> AFAIK, there's no fix. You can help the situation somewhat by calling System.gc() after every Bitmap.recycle() call, and again before every bitmap allocation. But that's only somewhat. I've also found that setting bitmap variables to null after recycling them makes matters worse, but YMMV.
On Sat, Feb 26, 2011 at 2:35 AM, seanw <bitshift...@googlemail.com> wrote:
> On Friday, February 25, 2011 8:12:29 PM UTC, Sheado wrote:
>> ...
> Dianne - that explains a lot, thank you. Is there any way to get an >> accurate (bitmap included) picture of the heap in pre-honeycomb builds >> of an app?
> The first one tells you how much memory is being used on the Dalvik heap > and the second one tells you how much is being used on the native heap.
> Regards,
> Sean
> -- > 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
