On Sep 18, 5:49 pm, fadden wrote:
> I don't know anything about how Maps works, so I can't offer any
> specific advice there. Something is using lots of memory, and until
> it stops, this will be a problem. :-(
I understand Andy, I was just wondering if you could answer my
question above:
Shor
On Sep 18, 9:01 am, Peter Jeffe wrote:
> Andy and Adam, any further comment? I'd like to believe that there's
> something developers can do to minimize the impact of these problems
> on end users. I think you can appreciate that having an application
> crash repeatedly through no fault of one's
Andy and Adam, any further comment? I'd like to believe that there's
something developers can do to minimize the impact of these problems
on end users. I think you can appreciate that having an application
crash repeatedly through no fault of one's own is very disheartening.
--~--~-~--~
On Sep 11, 6:53 pm, fadden wrote:
> It works something like this:
Thanks Andy, this discussion has definitely clarified things for me.
Of course the frustrating part is that we have no control over this
code, so there's probably no way to influence its use of external
memory. Short of forcing G
On Aug 27, 10:54 pm, Ramesh wrote:
> 08-28 11:16:26.785: ERROR/AndroidRuntime(1433): Uncaught handler:
> thread main exiting due to uncaught exception
> 08-28 11:16:26.825: ERROR/AndroidRuntime(1433):
> java.lang.OutOfMemoryError: bitmap size exceeds VM budget
> 08-28 11:16:26.825: ERROR/AndroidR
On Sep 11, 3:59 pm, Peter Jeffe wrote:
> It seems to me that the issue is a question of time lag more than
> anything else. Is it possible that trackExternalFree() isn't being
> called soon enough after every de-allocation of external memory?
It works something like this:
- Bitmap objects liv
Below is some output when I was zooming in maps, not sure if this
sheds light on anything. Since this is unrelated to anything in my
app it's obviously something that anyone can exercise.
It seems to me that the issue is a question of time lag more than
anything else. Is it possible that trackE
On Sep 10, 5:54 pm, Peter Jeffe wrote:
> 09-11 00:45:00 .maps(649) softlim=13120KB, extlim=7232KB,
> extalloc=7232KB
> freed 1136 objects / 115712 bytes in 84ms
> 09-11 00:45:01 .maps(649) softlim=13568KB, extlim=8128KB,
> extalloc=8128KB
> freed 3920 objects / 954368 bytes in 94ms
This isn'
On Sep 10, 2:14 pm, fadden wrote:
> If you see softlim+extlim approaching 16MB, you're about to have a
> problem. extlim and exalloc will give you a sense for how much memory
> is assigned to external allocations. The actual virtual heap limit
Thanks Andy, although I must confess I'm as confus
On Sep 9, 10:18 am, Peter Jeffe wrote:
> I should have said more clearly that in the case of these external
> allocations it's acting like it can't grow the heap--i.e. there's a
> hard limit that it hits against. Why is that the case? As many
> threads on this subject for the last year have att
On Sep 9, 11:27 am, Dianne Hackborn wrote:
> Of course it can grow the heap. It will also use mmap for allocations over
> 64K so they aren't in the main heap at all. (Fwiw, the allocator is a
> somewhat modified version of the standard dlmalloc.)
I should have said more clearly that in the cas
On Wed, Sep 9, 2009 at 9:19 AM, Peter Jeffe wrote:
> I assumed that the problem is that the native code tries to allocate
> memory but the native allocator for some reason can't move the heap
> boundary--basically it seems like Android's malloc() doesn't just call
> brk() or its equivalent when i
On Aug 28, 3:17 pm, fadden wrote:
> The bitmap memory isn't actually stored on the VM heap -- it's an
> "external allocation" -- so improvements to the GC will not help this
> much.
I assumed that the problem is that the native code tries to allocate
memory but the native allocator for some reas
On Aug 28, 12:49 am, "Mark Murphy" wrote:
> Strategically, find ways to help out with improvements to the Android
> garbage collector.
The bitmap memory isn't actually stored on the VM heap -- it's an
"external allocation" -- so improvements to the GC will not help this
much.
A compacting GC wo
I had better to check
> > > and
> > > release the memory every time?
>
> > > -Original Message-
> > > From: android-developers@googlegroups.com
> > > [mailto:android-develop...@googlegroups.com] On Behalf Of Mark Murphy
> > > Sent: Wednes
> Even after trying these methods i am getting the same error. The issue
> is in my application i am trying to load lots of images and when i
> navigate from one view to other, it still increases the memory. i.e.
> it's not freeing up / optimizing the memory which is now unused.
>
> Any idea how t
rs@googlegroups.com
> > [mailto:android-develop...@googlegroups.com] On Behalf Of Mark Murphy
> > Sent: Wednesday, July 01, 2009 11:38 AM
> > To: android-developers@googlegroups.com
> > Subject: [android-developers] Re: Is the limit of memory heap only 6M?
>
> > 楊健 wro
ted.
> > I thought at that time I just to allocate for 1.2M.
> > Is it means it is very dangerous to load picture ,I had better to check and
> > release the memory every time?
>
> > -Original Message-
> > From: android-developers@googlegroups.com
> > [mailto:androi
roups.com
> [mailto:android-develop...@googlegroups.com] On Behalf Of Mark Murphy
> Sent: Wednesday, July 01, 2009 11:38 AM
> To: android-developers@googlegroups.com
> Subject: [android-developers] Re: Is the limit of memory heap only 6M?
>
> 楊健 wrote:
> > 07-01 11:32:02.192: V
y
> Sent: Wednesday, July 01, 2009 11:38 AM
> To: android-developers@googlegroups.com
> Subject: [android-developers] Re: Is the limit of memory heap only 6M?
>
> 楊健 wrote:
> > 07-01 11:32:02.192: VERBOSE/QualcommCameraHardware(35): state
> > transition QCS_WAITING_JPEG
every time?
-Original Message-
From: android-developers@googlegroups.com
[mailto:android-develop...@googlegroups.com] On Behalf Of Mark Murphy
Sent: Wednesday, July 01, 2009 11:38 AM
To: android-developers@googlegroups.com
Subject: [android-developers] Re: Is the limit of memory heap only 6M
楊健 wrote:
> 07-01 11:32:02.192: VERBOSE/QualcommCameraHardware(35): state
> transition QCS_WAITING_JPEG --> QCS_IDLE
> 07-01 11:32:02.232: ERROR/dalvikvm-heap(395): 6291456-byte external
> allocation too large for this process.
> 07-01 11:32:02.232: ERROR/(395): VM won't let us allocate 6291456
>
22 matches
Mail list logo
