On Mar 4, 9:11 pm, Streets Of Boston flyingdutc...@gmail.com wrote:
I think that Dalvik does not 'see' any memory held by raw bitmap data
and therefore cannot consider it during garbage collection (gc). So,
it may not even try to gc when process-memory get low.
Actually, this is why the
Don't feel sorry Bob,
Your answer was totally appropriate and a good read, I didn't know
that this fragmentation problem could occur.
It was not the answer to this one, but again, you made Fadden give a
thorough explanation(Thank you Fadden). That's how forums and ideas
work, make them bounce :)
Btw, how do SQLite databases fit in here? Does SQLite run inside an
app's process and does it consume memory from the external
allocation space? Does it have limits in memory allocation or will it
just grab any memory it can make use of?
(The app I wrote about earlier does not use SQLite, I was
On Mar 3, 10:55 pm, Markus Junginger mar...@greenrobot.de wrote:
I have not been able to see the heap size shrink yet. Is there any way
(directly or indirectly) to trigger the HeapWorker manually?
Unfortunately there are multiple concepts that sort of get smashed
together:
(1) the virtual
... and Dalvik does not seem to make any attempts to shrink its heap
size ...
That's what i think as well.
I think that Dalvik does not 'see' any memory held by raw bitmap data
and therefore cannot consider it during garbage collection (gc). So,
it may not even try to gc when process-memory get
Yes, you're right.
The OOM exception is thrown if your process' memory would exceed
16MByte (or 24MByte on some phones). This includes non-JVM memory such
as raw bitmap-data. You may have 9MByte available in the java-heap,
but if your process is still holding on to almost 7MByte of bitmap-
data
On 3 Mrz., 23:01, Streets Of Boston flyingdutc...@gmail.com wrote:
Yes, you're right.
I hope I am not, let's see...
The OOM exception is thrown if your process' memory would exceed
16MByte (or 24MByte on some phones). This includes non-JVM memory such
as raw bitmap-data.
That's the easy part.
catch( Exception e )
{
System.gc();
bm = BitmapFactory.decodeResource( resources, R.drawable.my_bm );
}
I know it's not the prettiest, but I've never seen the second attempt
(after GC) fail.
Interesting. So, what you are saying is that Dalvik's GC does not a
good job freeing memory
?? If you have verified this, please report it as a bug.
The way GC works, GC work should be triggered by any allocation that
needs more memory (incremental algorithms trigger some amount of GC
work on each allocation, non-incremental algorithms do ALL the work in
this situation). The allocation
Generally, non-compacting GCs, and non-compacting/consolidating
allocators in general, cannot free memory back to the OS once it's
been used.
There are exceptions, such as when the object size is significantly
larger than the minimum OS memory allocation size. (By OS here, I
mean whatever lower
On Wed, Mar 3, 2010 at 6:21 PM, Bob Kerns r...@acm.org wrote:
?? If you have verified this, please report it as a bug.
To who? The same Google engineers that can't fix my Marketplace stats
since December?
http://www.google.com/support/forum/p/Android+Market/thread?tid=4c5752ca3e5af4ffhl=en
I
On Mar 3, 4:33 pm, Bob Kerns r...@acm.org wrote:
Generally, non-compacting GCs, and non-compacting/consolidating
allocators in general, cannot free memory back to the OS once it's
been used.
I'm not entirely comfortable with that generalization. The HeapWorker
thread wakes up during idle
Whoa, dude! Get a grip.
If you don't trust the Google engineers to fix things, not reporting
them seems like a sure solution, right?
And I didn't say you were doing it wrong. You just cut what I said up
into little pieces so you could pick at it. I gave reasons why you
were doing it right in
The key word here is 'generally', which I guess wasn't clear. What I
was trying to get at is, it can only happen under specific
circumstances, and only if the particular system implements it.
Which means, one small object in the middle of each 4K page can
completely prevent returning the memory
I'd like to add: I'm glad you're here to catch me when I'm unclear (or
even wrong). You do a very good job with your explanations.
I didn't mean my response below to suggest that my wording is right
-- obviously, it failed. I was just trying to salvage my intended
meaning from the wreckage. I
Thanks guys for all of your replies so far!
I'm not entirely comfortable with that generalization. The HeapWorker
thread wakes up during idle moments and looks for 4K pages with
nothing in them. When it finds them, the memory is made available to
the system again (madvise() system call).
I
16 matches
Mail list logo
