Are you running on the emulator or a device? There are some reports
that on the emulator, espeically in debug mode, memory is not GC'd
because the debugger is holding a refernece. I haven't experimented to
see if this is true but it is worth checking into.

You might try calling the GC prior to reallocating your variables.

I'm also wondering if you are following the activity model with proper
handling of onStart, onRestart, onPause, onResumer, etc. You may need
to be saving your large arrays to a file during onPause and reloading
them with onResume. (Or onStop and onRestart.)

Rud
http://mysticlakesoftware.blogspot.com/

On Jul 29, 2:15 pm, choff <choff_2...@hotmail.com> wrote:
> Hi I'm also a programmer on this project.
>
> These arrays are class variables of our Activity class.  When we
> change these from instance variables to static class variables it
> seems that the problem goes away in relation to these arrays ( we then
> start bumping into problems with other instance variables)  This would
> suggest that ANDROID itself is not letting go of the Activity
> instances.  That some how they are being queued up or hung on to... It
> also seems every time the app is relaunched a new Activity class is
> created.
>
> Does this have any merit?
>
> If so is there away to flush out the Activity between starts?
>
> On Jul 29, 2:10 pm, fadden <fad...@android.com> wrote:
>
>
>
> > On Jul 29, 9:42 am, RM <rick.manc...@gmail.com> wrote:
>
> > > 1.  Is memory saved in the Dalvik VM by using a short or byte vs. an
> > > integer?  I've read some conflicting things on how this works.  i.e.
> > > -- is the memory occupation as follows:
>
> > > Byte = 8bits
> > > Short = 16bits
> > > Int = 32bits
>
> > For arrays, yes.  Fields in objects are always 32 or 64 bits.
>
> > > 2.  Garbage collection strategies.  Specifically, I'm allocating a
> > > couple of large integer arrays in my main activity class.  My program
> > > runs fine once.  When I press the HOME button, however, and then re-
> > > launch the application it crashes when (re)allocating the arrays.
>
> > Catch the OOM and call the API we added in 1.5 that saves an HPROF
> > dump.  Examine the heap dump to see where your memory went.
> > Instructions are in dalvik/docs/heap-profiling.html:
>
> >  http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=d...
>
> > In particular, make sure there isn't something keeping your large
> > arrays around after you believe you're no longer referencing them.
>
> > While your application runs, it may be useful to keep an eye on the GC
> > stats being written to the event log.  dalvik/tools/gclog.py can help:
>
> >  http://bigflake.com/gclog.py.txt- 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 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to