I'd categorize it as a consequence of present VM implementation; something that could be improved rather than something that needs to be fixed (note that no one has actually corroborated whether my understanding of this memory allocation is correct).
Whether it's possible to improve the current memory allocation model without trading off too many of its benefits is a question for the engineers responsible, and whether this is something that is worth spending development time on is another question again. I don't know how the present situation is regarded by the Android engineers. For my part, I don't see it as a very high priority. I try to write applications that stay comfortably below their maximum memory allocation, so I don't generally find it a cause of errors in my applications. Naturally there are exceptions, applications that allocate data structures based on external data can't easily avoid memory spikes when processing large inputs. When a flat memory profile isn't attainable, pre-allocating your bitmaps may be the only workaround, though this may have the consequence of making out-of-memory conditions more frequent and not less. As ever, it depends on the application. Tom. On 27 August 2010 17:09, Viktor <[email protected]> wrote: > I read the thread you posted and I agree that this is probably the > same problem. Is this behaviour from android "working as intended" or > can we expect it to be fixed in later releases? Also did you ever find > a workaround, I read the part about not allocating large memory chunks > but sometimes that's necessary for some of the applications I'm > writing. > > BR Viktor > > On Aug 27, 4:19 pm, Tom Gibara <[email protected]> wrote: > > Viktor, This question comes up in various guises. I think your problem is > > explained by some old posts I made on this thread. > > > > http://groups.google.com/group/android-developers/browse_thread/threa... > > > > <http://groups.google.com/group/android-developers/browse_thread/threa.. > .> > > Tom. > > > > On 27 August 2010 08:34, Viktor <[email protected]> wrote: > > > > > > > > > Why wouldn't nulling b mark the array for garbage collection? What > > > other pointers to the array could there be? > > > > > I tried your suggestions with no success. > > > > > On Aug 25, 6:23 pm, DanH <[email protected]> wrote: > > > > OK, I see that you're nulling "b" between the two allocations. But > > > > that doesn't assure that all pointers to the array are destroyed. > Try > > > > placing the "= new" and "= null" statements in a called method (& > just > > > > for grins return b from that method and assign it in your original > > > > method). > > > > > > On Aug 25, 10:40 am, DanH <[email protected]> wrote: > > > > > > > The first array is 20 MB. The second is also 20 MB. What's the > > > > > problem? > > > > > > > On Aug 24, 4:28 pm, Viktor <[email protected]> wrote: > > > > > > > > I'm having some trouble understanding why this code > > > > > > > > public class BitmapAllocTest extends Activity { > > > > > > /** Called when the activity is first created. */ > > > > > > @Override > > > > > > public void onCreate(Bundle savedInstanceState) { > > > > > > super.onCreate(savedInstanceState); > > > > > > byte[] b = new byte[20 * 1000 * 1000]; > > > > > > b = null; > > > > > > Bitmap.createBitmap(2500, 2000,Bitmap.Config.ARGB_8888); > > > > > > }} > > > > > > > > throws an OutOfMemory exception on a device with a 24mb heap > limit. > > > If > > > > > > I comment out either of the allocations it runs fine. I was under > the > > > > > > impression that the java vm would try to garbage collect before > > > > > > throwing OutOfMemory exceptions. > > > > > > > > I suspect it having to do withandroidallocating the bitmaps on > the > > > > > > native heap. > > > > > > > > PS. This is a clone from my stackoverflow questionhttp:// > > > stackoverflow.com/questions/3546635/android-bitmap-allocation-... > > > > > > which hasn't gotten a satisfactory answer yet.- Hide quoted text > - > > > > > > - Show quoted text - > > > > > -- > > > 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]<android-developers%[email protected]> > <android-developers%2bunsubs[email protected]> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en- Hide quoted > text - > > > > - Show quoted text - > > -- > 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]<android-developers%[email protected]> > 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 [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
