Re: [android-developers] Re: Out of memory - despite being way under 16mb
Awesome, Thanks Sean - I'll definitely try that out. On Sat, Feb 26, 2011 at 2:35 AM, seanw 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? >> > > Hi, > > You can use these functions; > > Runtime.getRuntime().totalMemory() > android.os.Debug.getNativeHeapAllocatedSize()) > > 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+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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
[android-developers] Re: Out of memory - despite being way under 16mb
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? > Hi, You can use these functions; Runtime.getRuntime().totalMemory() android.os.Debug.getNativeHeapAllocatedSize()) 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Out of memory - despite being way under 16mb
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...
Here's my current code
public void onClick(View v) {
v.performHapticFeedback(HapticFeedbackConstants.LONG_PRESS);
System.gc();
try {
mMapView.getController().zoomIn();
} catch (OutOfMemoryError e) {
e.printStackTrace();
}
System.gc();
zoomLevel = mMapView.getZoomLevel();
SharedPreferences.Editor editor = settings.edit();
editor.putInt("zoomLevel", zoomLevel);
editor.commit();
}
On Feb 25, 6:07 pm, String wrote:
> Sounds to me like you are probably hitting the bitmap deallocation
> problem:http://code.google.com/p/android/issues/detail?id=8488
>
> 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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Out of memory - despite being way under 16mb
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 wrote: > Sounds to me like you are probably hitting the bitmap deallocation > problem:http://code.google.com/p/android/issues/detail?id=8488 > > 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Out of memory - despite being way under 16mb
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 wrote: > Sounds to me like you are probably hitting the bitmap deallocation problem: > http://code.google.com/p/android/issues/detail?id=8488 > > 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+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- 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
[android-developers] Re: Out of memory - despite being way under 16mb
Sounds to me like you are probably hitting the bitmap deallocation problem: http://code.google.com/p/android/issues/detail?id=8488 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Out of memory - despite being way under 16mb
Thanks for the responses. 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 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 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: > > >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. > > > 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+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > 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
[android-developers] Re: Out of memory - despite being way under 16mb
Can you post your code? It is easier to find what's happening in that way. On Feb 24, 2:42 pm, Sheado 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: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. > > 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
