Rewrite: Out of memory

[emux]

Hi Thilo,

I test rewrite branch at large resolutions in order to see if the main branch memory issues still exist.
Unfortunately I see them more often.

For example at a LGE G-Slate v9xx tablet of 8.9" screen with 1280x768 resolution at application launch the 1st OOM "FATAL EXCEPTION: MapWorker" is thrown after a few tiles draw.

If the map view is loaded successfully, then when I try rotate the tablet in order to change its orientation, the 2nd OOM "FATAL EXCEPTION: main" is thrown.

For the record I try with both my application and the Rewrite sample app with the same OOM result.

FATAL EXCEPTION: MapWorker
java.lang.OutOfMemoryError
    at android.graphics.Bitmap.nativeCreate(Native Method)
    at android.graphics.Bitmap.createBitmap(Bitmap.java:604)
    at android.graphics.Bitmap.createBitmap(Bitmap.java:584)
    at org.mapsforge.map.android.graphics.AndroidBitmap.<init>(AndroidBitmap.java:46)
    at org.mapsforge.map.android.graphics.AndroidGraphicFactory.createBitmap(AndroidGraphicFactory.java:104)
    at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:157)
    at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:63)
    at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:45)
    at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)

FATAL EXCEPTION: main
java.lang.OutOfMemoryError
    at android.graphics.Bitmap.nativeCreate(Native Method)
    at android.graphics.Bitmap.createBitmap(Bitmap.java:604)
    at android.graphics.Bitmap.createBitmap(Bitmap.java:584)
    at org.mapsforge.map.android.graphics.AndroidBitmap.<init>(AndroidBitmap.java:46)
    at org.mapsforge.map.android.graphics.AndroidGraphicFactory.createBitmap(AndroidGraphicFactory.java:104)
    at org.mapsforge.map.view.FrameBuffer.setDimension(FrameBuffer.java:78)
    at org.mapsforge.map.controller.FrameBufferController.onChange(FrameBufferController.java:65)
    at org.mapsforge.map.model.common.Observable.notifyObservers(Observable.java:48)
    at org.mapsforge.map.model.MapViewModel.setDimension(MapViewModel.java:34)
    at org.mapsforge.map.android.view.MapView.onSizeChanged(MapView.java:139)
    at android.view.View.setFrame(View.java:9661)
    at android.view.View.layout(View.java:9575)
    at android.widget.FrameLayout.onLayout(FrameLayout.java:400)
    at android.view.View.layout(View.java:9581)
    at android.view.ViewGroup.layout(ViewGroup.java:3877)
    at android.widget.LinearLayout.setChildFrame(LinearLayout.java:1542)
    at android.widget.LinearLayout.layoutVertical(LinearLayout.java:1403)
    at android.widget.LinearLayout.onLayout(LinearLayout.java:1314)
    at android.view.View.layout(View.java:9581)
    at android.view.ViewGroup.layout(ViewGroup.java:3877)
    at android.widget.FrameLayout.onLayout(FrameLayout.java:400)
    at android.view.View.layout(View.java:9581)
    at android.view.ViewGroup.layout(ViewGroup.java:3877)
    at android.view.ViewRoot.performTraversals(ViewRoot.java:1253)
    at android.view.ViewRoot.handleMessage(ViewRoot.java:2003)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loop(Looper.java:132)
    at android.app.ActivityThread.main(ActivityThread.java:4025)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:491)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599)
    at dalvik.system.NativeStart.main(Native Method)

[Thilo Mühlberg]

Which Android version is running on that particular tablet device? My
Nexus 4 device (Android 4.2) has exactly the same screen resolution but
I never had any memory problems with it in the rewrite branch.

Greetings,
Thilo

> --
> You received this message because you are subscribed to the Google
> Groups "mapsforge-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mapsforge-de...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[emux]

Hi Thilo,

It's the following tablet:
http://www.gsmarena.com/lg_optimus_pad_v900-3835.php
with Android OS, v3.2 (Honeycomb).

That means that Nexus 4 has more native/VM heap size than LG tablet..?
Because as another user wrote at mailing list, at Honeycomb there was a change at the heap type that the bitmaps are stored (native heap - vm heap).
For the record, similar memory conversation is at:
http://code.google.com/p/mapsforge/issues/detail?id=378
with Ludwig.

I'll try more tests and on a Nexus 7 that I saw some memory issues at the past with the master branch, specially after tablet orientation changes.

[emux]

Hi,

Trying to use custom direction arrow for my location I notice the following issue concerning Canvas size.

Measured in MyLocationOverlay.draw method at master branch the Canvas size is exactly the MapView size.

At rewrite branch the Canvas size is larger than MapView size. Why there is such a difference?
Doesn't it consumes more memory than older implementation?

Thanks.

[Thilo Mühlberg]

The canvas size is larger in the rewrite branch because the whole
redrawing has been moved to a separate thread. This relieves the GUI
thread and increases the frame rate. During touch event handling only a
matrix is manipulated (translated) which is used to draw the canvas.

The canvas has to be slightly larger than the actual view to compensate
for the asynchronous redrawing. Otherwise white regions at the border of
the view will appear when the map is moved until the canvas has been
redrawn. The size of the canvas can be configured, even at runtime. Just
use the model.frameBufferModel.setOverdrawFactor(double) method to
change it, currently the default value is 1.5 (width and height).

Greetings,
Thilo

[emux]

Hi Thilo,

I was able to test Rewrite samples app at a Nexus 7.
I used countries maps from mapsforge downloads. The Rewrite app starts at small zoom level.
I zoom in the map at about zoom level 8 where the woods start to draw for the whole country, which is a little bit slow.
Before the whole screen tiles can draw themselves I rotate the Nexus 7 in order to change its orientation (portrait/landscape).
Then a Out Of Memory exception is thrown and the Rewrite app closes.

Regards.

[Ludwig]

There are certainly memory issues with the rewrite branch. They can be reproduced on every device and every Android version I have tried. A few device rotations even on the simplest maps trigger OOM crashes.

I assume they are once again linked to the damn bitmaps.

One obvious problem for versions below Honeycomb is that the bitmaps do not get recycled with a call to bitmap.recycle().  Without the calls to recycle(), any app will invariably run out of memory. Unfortunately the whole infrastructure for this resource management is missing and needs to be added (again, this was more or less fixed in the current master).

Technically, the call to recycle() should not be required for versions from Honeycomb up, but from the investigations I made for the master branch a few months ago, canvas objects tend to hold references to the bitmaps, so that they do not get cleaned up unless the canvas is nulled out.

I am currently investigating, please stay tuned.

Ludwig

[Thilo Mühlberg]

This is really strange. I just tested it again with my Nexus 4 (running
Android 4.2) using the latest rewrite version and the germany map file.
I did 100 orientation changes but everything is still fine, no crash.

On an old LG P500 running Android 2.3.3 the application crashed after
approximately 20 orientation changes.

So to me it still looks like this is an issue with old Android version,
maybe due to the changes in the bitmap handling. But you say that you
can reproduce this problem even on devices running Android 4.2?

Greetings,
Thilo

On 28/04/13 06:09, Ludwig wrote:
> There are certainly memory issues with the rewrite branch. They can be
> reproduced on every device and every Android version I have tried. A few
> device rotations even on the simplest maps trigger OOM crashes.
>
> I assume they are once again linked to the damn bitmaps.
>
> One obvious problem for versions below Honeycomb is that the bitmaps do
> not get recycled with a call to bitmap.recycle(). Without the calls to
> recycle(), any app will invariably run out of memory. Unfortunately the
> whole infrastructure for this resource management is missing and needs
> to be added (again, this was more or less fixed in the current master).
>
> Technically, the call to recycle() should not be required for versions
> from Honeycomb up, but from the investigations I made for the master
> branch a few months ago, canvas objects tend to hold references to the
> bitmaps, so that they do not get cleaned up unless the canvas is nulled
> out.
>
> I am currently investigating, please stay tuned.
>
> Ludwig
>
>
>
>
>
>
>
> On 27 April 2013 20:06, emux <deve...@gmail.com

> <mailto:deve...@gmail.com>> wrote:
>
> Hi Thilo,
>
> I was able to test Rewrite samples app at a Nexus 7.
> I used countries maps from mapsforge downloads. The Rewrite app
> starts at small zoom level.
> I zoom in the map at about zoom level 8 where the woods start to
> draw for the whole country, which is a little bit slow.
> Before the whole screen tiles can draw themselves I rotate the Nexus
> 7 in order to change its orientation (portrait/landscape).
> Then a Out Of Memory exception is thrown and the Rewrite app closes.
>
> Regards.
>
> --
> You received this message because you are subscribed to the Google
> Groups "mapsforge-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to mapsforge-de...@googlegroups.com

> <mailto:mapsforge-dev%2Bunsu...@googlegroups.com>.

[Ludwig]

Yes, the OOM conditions are present in Android 4.x up to the very latest version. The problems are reproducible on physical devices and on emulators. It takes maybe 20 turns of my Nexus 10 just running the BasicMapViewer in the Samples app.

For a more mechanical reproduction I use a robotium-based test for the Samples app that automatically turns the emulator.

I have just pushed it to a branch on my clone: http://code.google.com/r/ludwigbrinckmann-mapsforge/source/list?name=rewrite-samples

The easiest way to use this would be to check-out the branch and then simply copy the Applications/Android/Samples_Test project and then run them as an Android JUnit project. I hope everything required is included, if not let me know.

The tests that fail first are the testScrollWithRotation(), eg. BasicMapViewerTest.testScrollWithRotation(). Without rotation I guess not enough bitmaps are allocated to make the app run out of memory.

That apps run out of memory is no surprise on Android 2.3.x (version 9 and 10) as the bitmaps do not get recycled. The call to bitmap.recycle() is essential for memory management in these versions and regrettably requires an explicit bitmap allocation and deallocation strategy. Dalvik just isn't working here.

(As I said in my last email, for 4.x the problem seemed to be a question of the canvas holding references to the bitmaps. What apparently happens is that the canvas gets marked for GC, but then the referenced bitmaps get gc'd only during the next GC at which point the app had run out of memory. One way of reducing the problem seemed to be to null out the canvas when not used anymore, thus speeding up GC for the bitmaps. But this is a bit speculative.)

I have, as a first step, tried to add some sort of resource management to the MapView in the form of a chain of destroy() calls down to the AndroidBitmap level where then a call to recycle is added. The main goal was first to simply make sure that all the bitmaps get cleaned up.
Unfortunately now I have run into some sort of race condition where a bitmap that has just been recycled is used, triggering a runtime exception, so this seems to require additional synchronization.

More later.

Ludwig

[Ludwig]

Just sharing some progress here.

As I said in my previous email, a form of explicit resource management is required to manage Android's Bitmap classes as, for versions <= 10, the associated memory is not cleaned up automatically in a reliable fashion resulting in OOM errors and app crashes.

I have had a look at the code base and the key difficulty is to know when the underlying Android Bitmap can be recycled() as the wrapper class AndroidBitmap can referenced in different locations, notably in the InMemoryCache and then also somewhere in the actual rendering process. (Eg, the bitmap is being ejected from the LRUCache, but the bitmap has been handed to the renderer for drawing. So the renderer cannot delete the bitmap as it does not know if the cache still requires it, while the cache removal may not delete it as it is just being drawn).

My solution is to add a reference counting mechanism to the AndroidBitmap wrapper class: this ensures that concurrent use of the AndroidBitmap objects is possible (so no recycle() while some other thread is still using the object). Calls to increment and decrement the refCount had to be added basically at those locations where an AndroidBitmap is added to the cache, when is taken from the cache (but of course remains inside as well), when an AndroidBitmap falls out of the cache (change to the LRUCache required) etc. Additional calling chains had to be introduced to clean up things like the MapScaleBar.

(I had tried versions without refCounting, but they will require additional synchronization and possibly changes in the whole model as I ran into problems where Bitmaps were recycled() and then still used.)

I am currently at the state where -- when I am using a rendertheme without png symbols -- the bitmaps get cleaned up ok in most cases. My automated tests show a few cases where bitmaps still leak, reason still unclear.

Test cases already run much better, of course particularly on 2.3 versions where the Bitmap leak is most severe, but so far I have not managed to crash the BasicMapViewer example from the Samples app on my Nexus 10 either. So this seems to be going in the right direction.

Using renderthemes with png symbols has its own Bitmap leak problem, but with the first problem mostly addressed, I am confident the approach can also be applied here.

I will share some code soon, but thoughts are welcome.

Ludwig

[Karussell]

Hi Ludwig,

not sure if it could be of some help but did you already use/know the WeakReference or PhantomReference classes?

Regards,
Peter.

[Ludwig]

Thanks Peter, that was the sort of comment I was hoping for.

But reading up on it, I am not sure if they can come to the rescue as what is needed is a more aggressive, deterministic memory cleanup to deal with the Android Bitmaps. But then maybe not enough of a Java Wizard to really understand how to put this to good use.

Anyway, I have just pushed one tentative solution to a branch at my clone at http://code.google.com/r/ludwigbrinckmann-mapsforge/source/list?name=rewrite-memory

This branch adds reference counting to the bitmaps adds cleaning up code to those classes that contain bitmaps together with calls to those destroy operations. I have also added a Robotium based Samples_Test app that excercises the Samples app.

(Note I was lazy, reference counting start at 0, and a bitmap gets destroyed if the ref count falls below 0).

This code generally seems to work, I left some minimal logging in place that counts the total number of Android bitmaps created. The count should fall to 0 after a mapsforge-based activity terminates.

However there is at least one notable exception where bitmaps still leak:

There is a race condition in the DatabaseRenderer: the DBR creates its RenderTheme by making a call to RenderThemeHandler and the result is assigned on return. However, if the activity is terminated before this call returns, the DBR does not yet have a reference to the RenderTheme (which is in the process of reading in all the symbols etc) and the memory associated with this leaks. This happens quite regularly, if I run the Sample_Test app against a 2.3.1 emulator (ARM emulated, so dead slow).

Another form where the cleanup using the DestroyThread is less than perfect are solutions where the DestroyThread waits for the rendererThread, sometimes so long that the app runs out of memory. Again, seems to happen on ARM-based emulator only.

I am not sure if this also happens in real life, if someone still has a 2.3 based device, I would be appreciate if you could run the samples app and see if this happens.

Also sometimes running the Samples_Test just a few AndroidBitmaps leak, the reason is still unclear. I have successfully run the Samples_Test against a 4.2 emulator, but in some runs out of the thousands of AndroidBitmaps, maybe four leak.

Just to make clear: I do not cling to any particular part of this solution, it is more an investigation of where the problem lies and of presenting one way how it can be solved. Better solutions and suggestions welcome.

Ludwig

[Ludwig]

I think I finally cracked the memory problems with rewrite.

Maybe I should read my own words more often, but the key thing that was missing to fix the bitmap leaks was to null out Android Canvas objects after they are not being used anymore. As with the fixes for the 0.3 version, only this lets finally go of the memory.

I have just pushed this to my clone at http://code.google.com/r/ludwigbrinckmann-mapsforge/source/detail?r=98aa9d4b32da811dbd92ed3084c759ed1af066c0&name=rewrite-memory

Included is also a fix for the race condition in the destruction of data associated with the DatabaseRenderer, I am not sure how prevalent this is in the real world.

The Samples app now caculates the required size for the first level cache according to screen size.

The Robotium-based Samples_Test app runs generally through now for all versions (including on Android 9 ARM based emulator), sometimes there are spurious test failures (through out-of-memory conditions or timing-related stuff in the test code), but the failures are rare now and occur much, much later.

Feedback welcome.

Ludwig

[Ludwig]

I think a decision should be made what to do with this. Clearly the bitmap problem needs a solution (apps crash without a fix) and the one I proposed is one. It might not be the best one, but it is the best one that has been presented here. I have tried other approaches, but I think this is the easiest with the least risk. A perhaps better way would be caching the allocated bitmaps for reuse (it is said to improve performance on Android 11+), but it requires significantly more changes.

I would suggest merging this into the rewrite branch as the key way to get more exposure and thus beta-testing before any 0.4 release.

Ludwig.

[Jürgen Broß]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ludwig and the others,

maybe I have a nice idea how to put the functionality of the
java.lang.ref package [1] to good use in our context. Consider this
mail as a request for comments.

Let me first summarize the problem setting as I understood it. Feel
free to correct me:

* In Android 2.3.3 and lower it is recommended to call
Bitmap.recycle() to free the native object and reclaim the associated
native memory as soon as possible [2].
* Bitmap.recycle() must only be called in the case when the Bitmap is
not needed anymore [3]. If we do not call recycle(), we end up with
OOM exceptions.
* Our goal is thus to detect the situation when a specific Bitmap is
not needed anymore.
* My assumption: "Not needed" translates to "the Bitmap is not
(strongly) reachable via the object graph". In other words, the Bitmap
can be garbage collected. We thus need to detect when a Bitmap can be
garbage collected and then call the recycle() method. Currently we do
so by our own reference counting mechanism in the wrapper class
AndroidBitmap.

If my assumptions are correct, then the following idea might be a
minimally invasive solution:

1. Each time a new AndroidBitmap wrapper is created, we also create a
Reference<AndroidBitmap> ref (a PhantomReference suffices for our
purposes).
2. With such a Reference, we register a central
ReferenceQueue<AndroidBitmap> queue. If the referred AndroidBitmap is
subject to garbage collection, the JVM will automatically add the
corresponding Reference<AndroidBitmap> reference to the queue.
3. Besides the ReferenceQueue<AndroidBitmap> queue, we also maintain a
Map<Reference<AndroidBitmap>, Bitmap> map that maps references to
native Bitmaps.
4. Now, in the case an AndroidBitmap is not needed anymore, the
corresponding Reference will be put to the central ReferenceQueue. We
use a separate high priority Thread that periodically scans the
ReferenceQueue by calling the poll() method in a while-not-null-loop.
The thread retrieves a Reference<AndroidBitmap> reference and uses the
map to retrieve the corresponding native Bitmap. The thread calls the
recycle() method and removes the map entry.

* The keys in the map must be References since otherwise the referred
AndroidBitmaps would always be reachable and never be garbage collected.
* The native Bitmap will not be garbage collected as it is still
referred by the map. So we can securely call the recyle() method and
afterwards remove the Bitmap from the map so that it can be garbage
collected in the next cycle.
* We can use PhantomReferences as we never need to use the reference
to retrieve the referred AndroidBitmap. We only use the references as
a key for the map.
* By using the described idiom with PhantomReferences we quasi get the
semantic of the Object.finalize() method without its disadvantages
(see [4] and [5]).
* The described approach is minimally invasive. We do not need to add
reference counting, but rely on the JVM's internal reachability tests.
We just need to add som book keeping code (ReferenceQueue + Map) at a
proper, central location and run an additional cleanup thread.


Is my understanding of the problem correct and are my assumptions
sound? Do I miss something with the Reference/ReferenceQueue mechanisms?

Regards,
J�rgen

[1]
http://developer.android.com/reference/java/lang/ref/package-summary.html
[2]
http://developer.android.com/training/displaying-bitmaps/manage-memory.html
[3]
http://developer.android.com/reference/android/graphics/Bitmap.html#recycle()
[4]
http://my.safaribooksonline.com/book/programming/java/9780137150021/creating-and-destroying-objects/ch02lev1sec7
[5]
https://weblogs.java.net/blog/2006/05/04/understanding-weak-references
(see section "Phantom references")

>>> On 28 April 2013 19:08, Thilo M�hlberg

- --


J�rgen Bro�
Institute of Computer Science
Databases and Information Systems
Freie Universit�t Berlin
Takustr. 9
D-14195 Berlin, Germany
phone: +49 30 838-75108
email: juerge...@fu-berlin.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJRyCMCAAoJEGru9gazV4GKRFcP/0G1hbP6nHw8DrvpBYLoFDCO
CUzB8+HrCLB6hcUrtXEFDM9yEx9Xy9qyeyZB3pMxBCV9DNhCu2r/xTeraFK95UDb
d1PnusMyiLZciedL2aN66YUEIE663eY0ywma8D5Jo1VtyEJ5xxoSp0C88pU4GOQt
/ceUhbuG4UEOZLb9X5URndl1txQgGcVY6+31kOuVi8sXeP+22XvXvK7qvtrJf01Z
S3I41xnbkhBTF75mvlzf6eNjusnbG7Yahz3DhJm5xa8PO8GPJNZIIfufyJLysebE
WbVO0/TeLXB0LwZk1RIJjgo2CwsOpvlouj7rY3ZH9qd9PGpQorj33mi7frN6aACy
CSI6Df78bxlg1+5VNCcv61a207euN8h13fDD74w21u8K5bi1RiOu3tW+NVh7VQEu
WA14Wk3j1wvqy/85wk/ans2rc8W0pdffp6nVgRJhPUSAyQb3C/A+QHOfQWGcw5YC
lOmLX/1ADs1AUrUa+xqr/zobG4ROGPInlSy+PBD7PwIZf8NG6luNSkn3bRhFUPTC
iac0VE8KaBGFqiEbG4YoM8RyQe+kfCYww6wCi7duGWG9O2T2shuNjZVBB4gbA9Q2
twJOnuTQDjKJInq4rdt1Lxe2It/+8chi4w1nggQi+7nh3hoKq3M3zMtZJeFwZkkK
l80zBHdjZBZr6giwLABg
=prfK
-----END PGP SIGNATURE-----

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

The proof of the pudding is in the eating here as we do not really
know what is going on behind the scenes: so short of implementing this
we have no chance of knowing for sure.

However, I have my concerns, both from a conceptual and a practical
point of view:

Conceptually, I do not think your suggestion is really simpler than
the reference counting approach that I took (which BTW is Google's
official suggestion on how to handle it for Android < Honeycomb
(http://developer.android.com/training/displaying-bitmaps/manage-memory.html).
I am particularly a wary of anything that requires another thread to
do work that can be done cleanly inline.

But I also do not think that this approach, even if implemented
perfectly, will work: the problem is not that bitmap memory does not
get released. The problem is that it does not get released _in time_
and meanwhile the process crashes. I actually suspect that the
internal implementation for Android < Honeycomb is something like what
you are suggesting: this works as long as there is not a situation
where many bitmaps get released (or queued for release) while at the
same time many bitmaps get allocated again (as we are seeing when a
device is rotated). It is this burst behaviour that kills the process
and that is why an aggressive and deterministic approach is needed:
introducing a thread to handle this makes this cleanup needlessly
non-deterministic and while it might (will?) handle some of the
situations, there will clearly be some where it will fail simply
because of thread scheduling.
(In addition there is the problem that bitmap memory only gets
recycled once their 'associated' canvas gets cleaned up).

The same, phrased a bit differently:
When a device rotation happens, AndroidBitmaps get released. With the
reference counting approach, the underlying bitmaps get recycled there
and then in a deterministic fashion. Memory immediately becomes
available for allocation by the restarted activity.

Relying on the system GC to trigger the cleanup process is simply too
late: at the rotation point the GC is triggered because there is not
enough memory to allocate a new bitmap, maybe call this an 'emergency'
GC. The GC frees whatever it can before program resumes, but in your
suggestion cannot free the system bitmap memory directly: this is done
by the extra thread. However, now you require that your additional
thread is scheduled next, before control is returned to the thread
that was trying to allocate the bitmap. However, there is not
guarantee that this will happen, so processes will IMHO still run out
of memory and crash.

With their implementation, the Android engineers broke the Java
contract by moving memory out of reach of the GC. But in this
situation, the GC is called because the process needs memory _right
now_. Anything that happens after this GC run, is too late. Process
dead. If there was a generic, non-intrusive solution, Google could
have published this a part of the support libraries or suggested this
themselves. They have not. They are suggesting reference counting.

At the same time, I have another suggestion, one that I have so far
shied away from because it involves more changes to the mapsforge core
library. This change would make the 2.3 situation marginally better by
making bitmap tracking easier, but the main benefit would be for 3+ by
allowing reuse of bitmap memory.

Fundamentally, we have two types of bitmaps in mapsforge:
1) bitmaps for tiles
2) bitmaps for icons etc

The tile bitmaps are all the same size and can be reused for the next
tile rather than allocating fresh. This is something that Google
recommends for bitmap use from 3.0 onwards.

In our case, the icon bitmaps are more tricky, mainly we do not know
their size until they have been created via the BitmapFactory: to
reuse them we need to know the size before reading in the image file.

At the moment, we do not have a way of distinguishing them, but
introducing a derived class TileBitmap that is used as container for
the tile bitmaps would allow to have a different life-cycle management
for these tiles. (AwtTileBitmap would just inherit the behaviour of
the AwtBitmap).

The bitmaps associated with renderthemes would benefit greatly if we
were not actually recreating renderthemes with every rotation, but
instead mark the rendertheme associated data as NonConfigurationChange
data.

I will think about your suggestion a bit more, but the more I have
thought about it already, the more convinced I have become that it
just cannot work reliably.

Ludwig








-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJRymJVAAoJEGtrzJg84vSRPZIIAIrIt0oSOPIc+SaFrHubOn03
Txhgmr9xI11KDqBgkcKvXTfdx+EY5BT5B3Ye1JcMbsTlA2Ho8Nc6qZN7wNkG8qla
kzzOycCMWQLrXR2MvcQlEwrazSDRQxP1ap8R1QzZ/dz3FkB6yavb8FiHuayWhLYA
zh+iSoc7jxWq5yG/hIw2PTBkyL1Rbs2Cj+cxQNa/gjavO8SOdGC+TLI6YYacEnCL
jCUSr6qMm4W8SDKnI+Da/Hu/L3agfN58/U05+XusE8F+f6rMUb7z9OgsQDA2U9Is
FpBgurF7ZPyIKNz6KqmYbAMzovmL+7KOb4w25Jv/xXCr4eB7opNNk9NIb+Mnicw=
=VksI
-----END PGP SIGNATURE-----

[Thilo Mühlberg]

A maybe stupid idea that just came to me:
What if we don't add a separate thread to clean up the bitmaps asynchronously but rather do that synchronously, for example each time a new bitmap is created via the bitmap factory. Iterating through all map entries and calling bitmap.recycle on each value should be very fast. Most of the time the map would probably empty anyway so no delay would be added at all.
We could make the method to start this cleanup process public so that the enclosing activity may also call it when onDestroy is called, that means before the rotation and application restart happens.
Besides that I agree that we can at least reduce the problem by reusing tile bitmaps. In particular the TileLayer can use the same bitmap to read from the tile caches and draw its content ...

[Ludwig]

But we would first need to mark those bitmaps that can be recycled....Jürgen's idea was based on utilizing the GC to tell us which ones are not reachable anymore, but that is too late as the process is just about to crash. The other way to know is via refcounting, but then we can recycle right away. Or am I missing something in your idea?

I was concerned you would not like the TileBitmap idea, so I had not proposed that earlier. I had an implementation of this based on Google's suggestion for bitmap management for Android 3.0+ https://developer.android.com/training/displaying-bitmaps/manage-memory.html, but it fell a bit short of my expectations as the reuse strategy can only be employed for those bitmaps where the size is known in advance (i.e. tiles in our case). The icons all vary in size and at the point where read them into a bitmap we only have an input stream without any size information (and reading twice is of course not possible/desirable). I will look into resurrecting that code, so people can have a look at it. Dealing with the bitmaps for icons could be done only if we carried more info into the bitmap creation process than just the inputstream.

Ludwig

[Ludwig]

I have had another day experimenting with this and my experiments have shown that with few exceptions the reference counting approach cleans up bitmaps reliably and in time.


Bizarrely, the whole thing seems to be working better on 2.3 than on 3.0 which should not have the leak problem (as I can get my Nexus 10 to run out of memory with monkey). The reason is unclear, but there are situations where the DestroyThread does not run in time for the rendertheme data to be cleaned up. (There is a point for handling the cleanup of the rendertheme differently, but this would require quite a few changes, so I would at this point in time advice against it). However, I have not managed to get it to crash manually, monkey just issues the directives much, much faster, leaving the device much less time to catch up (lots of other apps can be crashed that way).

I have actually implemented the TileBitmap idea, but the advantage of it is small as it lets us only reuse the bitmaps used for tiles in Android 3.0+ and has no impact on the bitmap memory leak problems in prior versions. It is an optimization (maybe), that might be worthwhile pushing into master for version 0.4.1 or so.

I have not tried Jürgen's suggestion as I really do not think it would work, for reasons explained in a previous email.

The version I have now is fundamentally the one that I pusblished out to my clone, which in turn is what we had in the old version, which is what Google advises. That approach has been in production for a long while now without anyone complaining about it, which to me means that it is good enough. Why break it? There is already a lot of change in the code base that needs to settle down, so my instinct would be against adopting anything that carries additional risk.

What this needs is exposure to testing by others, if someone finds a better scheme that actually works I am all for it, but trust me trying to account for all the bitmaps in different scenarios is not trivial.

Ludwig

[Maxime Guyon]

Hi,

I tested the sample application available on Jenkins server: Compilation #90 (4 juil. 2013 18:58:13)

So it's with the Germany map.

On my Iconia Tab A500 in 3.2.1 version i get easyly OOM error. For example if you start BasicMapViewer at zoom level which correspond to a 50km scale bar, then apps crash after loading some tiles.

Here is the stack trace since the start of BasicMapViewer to the crash (i touch nothing on the screen, i just let map loading at the 50km scale zoom):

07-19 11:07:54.710: I/ActivityManager(131): Starting: Intent { cmp=org.mapsforge.applications.android.samples/.BasicMapViewer } from pid 2612
07-19 11:07:54.780: I/dalvikvm(2612): Could not find method android.view.View.setBackground, referenced from method org.mapsforge.applications.android.samples.Utils.setBackground
07-19 11:07:54.780: W/dalvikvm(2612): VFY: unable to resolve virtual method 2339: Landroid/view/View;.setBackground (Landroid/graphics/drawable/Drawable;)V
07-19 11:07:54.780: D/dalvikvm(2612): VFY: replacing opcode 0x6e at 0x0006
07-19 11:07:54.870: D/dalvikvm(2612): GC_FOR_ALLOC freed 170K, 4% free 7217K/7495K, paused 23ms
07-19 11:07:54.890: I/dalvikvm-heap(2612): Grow heap (frag case) to 15.223MB for 8467216-byte allocation
07-19 11:07:54.920: D/dalvikvm(2612): GC_FOR_ALLOC freed 0K, 3% free 15486K/15815K, paused 20ms
07-19 11:07:54.950: D/dalvikvm(2612): GC_CONCURRENT freed 9K, 3% free 15476K/15815K, paused 2ms+2ms
07-19 11:07:54.970: D/dalvikvm(2612): GC_FOR_ALLOC freed 0K, 3% free 15476K/15815K, paused 21ms
07-19 11:07:54.980: I/dalvikvm-heap(2612): Grow heap (frag case) to 23.289MB for 8467216-byte allocation
07-19 11:07:55.000: D/dalvikvm(2612): GC_FOR_ALLOC freed 0K, 2% free 23745K/24135K, paused 21ms
07-19 11:07:55.070: D/dalvikvm(2612): GC_CONCURRENT freed 17K, 2% free 23772K/24135K, paused 1ms+4ms
07-19 11:07:55.360: I/ActivityManager(131): Displayed org.mapsforge.applications.android.samples/.BasicMapViewer: +604ms
07-19 11:07:55.470: D/dalvikvm(2612): GC_CONCURRENT freed 1613K, 7% free 24201K/25927K, paused 2ms+5ms
07-19 11:07:55.570: D/dalvikvm(2612): GC_FOR_ALLOC freed 1703K, 8% free 24268K/26375K, paused 27ms
07-19 11:07:55.730: D/dalvikvm(2612): GC_CONCURRENT freed 399K, 2% free 25931K/26439K, paused 2ms+4ms
07-19 11:07:55.880: D/dalvikvm(2612): GC_CONCURRENT freed 106K, 1% free 27885K/28103K, paused 2ms+4ms
07-19 11:07:56.050: D/dalvikvm(2612): GC_CONCURRENT freed 119K, 1% free 29855K/30087K, paused 1ms+3ms
07-19 11:07:56.240: D/dalvikvm(2612): GC_CONCURRENT freed 183K, 1% free 31710K/32007K, paused 1ms+4ms
07-19 11:07:56.590: D/dalvikvm(2612): GC_CONCURRENT freed 195K, 1% free 33565K/33863K, paused 2ms+4ms
07-19 11:07:56.930: D/dalvikvm(2612): GC_CONCURRENT freed 200K, 1% free 35416K/35719K, paused 2ms+5ms
07-19 11:07:57.290: D/dalvikvm(2612): GC_CONCURRENT freed 267K, 1% free 37205K/37575K, paused 2ms+6ms
07-19 11:07:58.230: D/dalvikvm(2612): GC_FOR_ALLOC freed 13864K, 36% free 25196K/39175K, paused 126ms
07-19 11:07:58.380: D/dalvikvm(2612): GC_CONCURRENT freed 142K, 31% free 27101K/39175K, paused 2ms+4ms
07-19 11:07:58.550: D/dalvikvm(2612): GC_CONCURRENT freed 102K, 26% free 29047K/39175K, paused 2ms+4ms
07-19 11:07:58.740: D/dalvikvm(2612): GC_CONCURRENT freed 149K, 22% free 30945K/39175K, paused 2ms+6ms
07-19 11:07:59.080: D/dalvikvm(2612): GC_CONCURRENT freed 290K, 17% free 32702K/39175K, paused 2ms+6ms
07-19 11:07:59.430: D/dalvikvm(2612): GC_CONCURRENT freed 184K, 12% free 34566K/39175K, paused 2ms+6ms
07-19 11:07:59.990: V/AlarmManager(131): --- from triggerAlarmsLocked operation: com.acer.android.widget.digitalclock
07-19 11:07:59.990: I/AlarmManager(131): ----Alarm type: 1Second:1374225300.0
07-19 11:07:59.990: I/AlarmManager(131): Alarm type : 1, from setRepeating operation : android
07-19 11:07:59.990: I/AlarmManager(131): ----Alarm type: 1Second:1374224940.0
07-19 11:08:00.010: D/appWidgetIds(659): 6
07-19 11:08:00.230: D/dalvikvm(2612): GC_CONCURRENT freed 10409K, 34% free 26205K/39175K, paused 2ms+6ms
07-19 11:08:00.360: D/dalvikvm(2612): GC_CONCURRENT freed 230K, 29% free 28022K/39175K, paused 2ms+4ms
07-19 11:08:00.520: D/dalvikvm(2612): GC_CONCURRENT freed 134K, 24% free 29936K/39175K, paused 2ms+4ms
07-19 11:08:00.670: D/dalvikvm(2612): GC_CONCURRENT freed 449K, 20% free 31534K/39175K, paused 2ms+5ms
07-19 11:08:00.860: D/dalvikvm(2612): GC_CONCURRENT freed 94K, 15% free 33488K/39175K, paused 2ms+5ms
07-19 11:08:01.080: D/dalvikvm(2612): GC_CONCURRENT freed 227K, 10% free 35308K/39175K, paused 2ms+5ms
07-19 11:08:01.430: D/dalvikvm(2612): GC_CONCURRENT freed 217K, 6% free 37139K/39175K, paused 1ms+5ms
07-19 11:08:01.840: D/dalvikvm(2612): GC_CONCURRENT freed 237K, 1% free 38963K/39303K, paused 2ms+7ms
07-19 11:08:02.190: D/BatteryService(131): level:71 scale:100 status:3 health:2 present:true voltage: 3897 temperature: 348 technology: Li-ion AC powered:false USB powered:false icon:17302707 invalid charger:0
07-19 11:08:02.280: D/dalvikvm(2612): GC_CONCURRENT freed 292K, 1% free 40764K/41159K, paused 2ms+7ms
07-19 11:08:03.470: D/dalvikvm(2612): GC_CONCURRENT freed 16552K, 39% free 26345K/42951K, paused 2ms+4ms
07-19 11:08:03.610: D/dalvikvm(2612): GC_CONCURRENT freed 144K, 35% free 28249K/42951K, paused 2ms+4ms
07-19 11:08:03.780: D/dalvikvm(2612): GC_CONCURRENT freed 118K, 30% free 30179K/42951K, paused 2ms+4ms
07-19 11:08:03.960: D/dalvikvm(2612): GC_CONCURRENT freed 112K, 26% free 32115K/42951K, paused 2ms+5ms
07-19 11:08:04.250: D/dalvikvm(2612): GC_CONCURRENT freed 225K, 21% free 33938K/42951K, paused 2ms+5ms
07-19 11:08:04.600: D/dalvikvm(2612): GC_CONCURRENT freed 216K, 17% free 35769K/42951K, paused 2ms+6ms
07-19 11:08:04.960: D/dalvikvm(2612): GC_CONCURRENT freed 158K, 13% free 37659K/42951K, paused 1ms+7ms
07-19 11:08:05.810: D/dalvikvm(2612): GC_CONCURRENT freed 12161K, 36% free 27545K/42951K, paused 2ms+4ms
07-19 11:08:05.970: D/dalvikvm(2612): GC_CONCURRENT freed 126K, 32% free 29466K/42951K, paused 2ms+4ms
07-19 11:08:06.140: D/dalvikvm(2612): GC_CONCURRENT freed 84K, 27% free 31430K/42951K, paused 2ms+4ms
07-19 11:08:06.320: D/dalvikvm(2612): GC_CONCURRENT freed 126K, 23% free 33351K/42951K, paused 1ms+4ms
07-19 11:08:06.510: D/dalvikvm(2612): GC_CONCURRENT freed 161K, 18% free 35237K/42951K, paused 2ms+4ms
07-19 11:08:06.720: D/dalvikvm(2612): GC_CONCURRENT freed 79K, 14% free 37205K/42951K, paused 2ms+4ms
07-19 11:08:06.940: D/dalvikvm(2612): GC_CONCURRENT freed 92K, 10% free 39050K/42951K, paused 2ms+3ms
07-19 11:08:07.280: D/dalvikvm(2612): GC_CONCURRENT freed 311K, 6% free 40787K/42951K, paused 2ms+5ms
07-19 11:08:07.680: D/dalvikvm(2612): GC_CONCURRENT freed 247K, 1% free 42588K/42951K, paused 2ms+6ms
07-19 11:08:08.090: D/dalvikvm(2612): GC_CONCURRENT freed 187K, 1% free 44453K/44743K, paused 1ms+6ms
07-19 11:08:08.490: D/dalvikvm(2612): GC_CONCURRENT freed 251K, 1% free 46308K/46663K, paused 1ms+8ms
07-19 11:08:08.910: I/dalvikvm-heap(2612): Clamp target GC heap from 49.178MB to 48.000MB
07-19 11:08:08.910: D/dalvikvm(2612): GC_CONCURRENT freed 208K, 1% free 48208K/48519K, paused 2ms+8ms
07-19 11:08:09.040: I/ActivityManager(131): Start proc com.smedio.mediaplayer for service com.smedio.mediaplayer/.WatchdogService: pid=2633 uid=10001 gids={3003, 1015, 3002}
07-19 11:08:09.230: I/dalvikvm-heap(2612): Clamp target GC heap from 49.880MB to 48.000MB
07-19 11:08:09.230: D/dalvikvm(2612): GC_CONCURRENT freed 129K, 1% free 48927K/49159K, paused 2ms+9ms
07-19 11:08:09.480: I/dalvikvm-heap(2612): Clamp target GC heap from 49.988MB to 48.000MB
07-19 11:08:09.480: D/dalvikvm(2612): GC_CONCURRENT freed 11K, 1% free 49038K/49159K, paused 2ms+10ms
07-19 11:08:09.710: I/dalvikvm-heap(2612): Clamp target GC heap from 49.992MB to 48.000MB
07-19 11:08:09.710: D/dalvikvm(2612): GC_FOR_ALLOC freed <1K, 1% free 49041K/49159K, paused 226ms
07-19 11:08:09.710: I/dalvikvm-heap(2612): Forcing collection of SoftReferences for 488-byte allocation
07-19 11:08:09.880: V/AlarmManager(131): --- from triggerAlarmsLocked operation: com.google.android.gsf
07-19 11:08:09.880: I/AlarmManager(131): ----Alarm type: 0Second:1374226689.896000000
07-19 11:08:09.890: I/EventLogService(242): Aggregate from 1374223089820 (log), 1374223089820 (data)
07-19 11:08:09.940: I/AlarmManager(131): Alarm type : 0, from setRepeating operation : com.google.android.gsf
07-19 11:08:09.940: I/dalvikvm-heap(2612): Clamp target GC heap from 49.992MB to 48.000MB
07-19 11:08:09.940: D/dalvikvm(2612): GC_BEFORE_OOM freed 12K, 1% free 49028K/49159K, paused 236ms
07-19 11:08:09.940: E/dalvikvm-heap(2612): Out of memory on a 488-byte allocation.
07-19 11:08:09.940: I/dalvikvm(2612): "MapWorker" prio=3 tid=10 RUNNABLE JIT
07-19 11:08:09.940: I/dalvikvm(2612):   | group="main" sCount=0 dsCount=0 obj=0x40888178 self=0x277c28
07-19 11:08:09.940: I/dalvikvm(2612):   | sysTid=2627 nice=13 sched=0/0 cgrp=bg_non_interactive handle=2587976
07-19 11:08:09.940: I/AlarmManager(131): ----Alarm type: 0Second:1374226689.950000000
07-19 11:08:09.950: I/dalvikvm(2612):   | schedstat=( 9555949000 568340000 5169 ) utm=927 stm=28 core=0
07-19 11:08:09.950: I/dalvikvm(2612):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.renderWay(DatabaseRenderer.java:~349)
07-19 11:08:09.950: I/dalvikvm(2612):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.processReadMapData(DatabaseRenderer.java:321)
07-19 11:08:09.950: I/dalvikvm(2612):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:152)
07-19 11:08:09.950: I/dalvikvm(2612):   at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:62)
07-19 11:08:09.950: I/dalvikvm(2612):   at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:44)
07-19 11:08:09.950: I/dalvikvm(2612):   at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)
07-19 11:08:09.960: W/dalvikvm(2612): threadid=10: thread exiting with uncaught exception (group=0x4015b760)
07-19 11:08:10.190: I/dalvikvm-heap(2612): Clamp target GC heap from 49.992MB to 48.000MB
07-19 11:08:10.190: D/dalvikvm(2612): GC_CONCURRENT freed <1K, 1% free 49029K/49159K, paused 2ms+3ms
07-19 11:08:10.400: D/dalvikvm(2612): GC_CONCURRENT freed 12771K, 27% free 36258K/49159K, paused 2ms+3ms
07-19 11:08:10.400: E/AndroidRuntime(2612): FATAL EXCEPTION: MapWorker
07-19 11:08:10.400: E/AndroidRuntime(2612): java.lang.OutOfMemoryError
07-19 11:08:10.400: E/AndroidRuntime(2612): at org.mapsforge.map.layer.renderer.DatabaseRenderer.renderWay(DatabaseRenderer.java:349)
07-19 11:08:10.400: E/AndroidRuntime(2612): at org.mapsforge.map.layer.renderer.DatabaseRenderer.processReadMapData(DatabaseRenderer.java:321)
07-19 11:08:10.400: E/AndroidRuntime(2612): at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:152)
07-19 11:08:10.400: E/AndroidRuntime(2612): at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:62)
07-19 11:08:10.400: E/AndroidRuntime(2612): at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:44)
07-19 11:08:10.400: E/AndroidRuntime(2612): at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)
07-19 11:08:10.400: W/ActivityManager(131):   Force finishing activity org.mapsforge.applications.android.samples/.BasicMapViewer
07-19 11:08:11.000: V/AlarmManager(131): --- from triggerAlarmsLocked operation: android
07-19 11:08:11.000: I/AlarmManager(131): ----Alarm type: 3Second:5509.93000000
07-19 11:08:11.010: I/ActivityManager(131): Start proc com.acer.ap.sns for service com.acer.ap.sns/.service.SNSService: pid=2643 uid=10013 gids={3003, 1015}
07-19 11:08:11.090: I/ActivityThread(2643): Pub com.acer.ap.sns.db.DBProvider: com.acer.ap.sns.db.DBProvider
07-19 11:08:11.100: I/SocialJogger(2643): SNSService onCreate
07-19 11:08:11.120: I/SocialJogger(2643): There is 4 groups now, current order: 2
07-19 11:08:11.120: I/SocialJogger(2643): SNSService onStartCommand + [com.acer.ap.sns.service.ACTION_AUTO_REFRESH_TRIGGERED]
07-19 11:08:11.120: I/SocialJogger(2643): SNSservice scheduleAlarmTriggered but SNSManager is not ready
07-19 11:08:11.120: I/ActivityManager(131): Start proc com.acer.ap.sns.webservice.SNSWebService for service com.acer.ap.sns/.webservice.SNSWebService: pid=2651 uid=10013 gids={3003, 1015}
07-19 11:08:11.140: I/SocialJogger(2643): CachedImageService onCreate
07-19 11:08:11.140: I/SocialJogger(2643): CachedImageService onbind
07-19 11:08:11.190: I/SocialJogger(2643): SNSManager is ready
07-19 11:08:12.130: I/SocialJogger(2643): SNSservice is starting to refresh posts
07-19 11:08:12.150: I/SocialJogger(2643): SNSService refresh posts complete [0, 0, -100]
07-19 11:08:12.150: I/SocialJogger(2643): Not to clear cache images because clear expired cache image one time in half a day
07-19 11:08:12.150: I/SocialJogger(2643): SNSservice the auto refresh is enabled [1800000]
07-19 11:08:12.150: I/SocialJogger(2643): SNSservice stopRepeatingListener
07-19 11:08:12.150: I/SocialJogger(2643): SNSservice startRepeatingListener, interval: 1800000
07-19 11:08:12.150: I/SocialJogger(2643): SNSservice isShowNotification: false
07-19 11:08:12.150: I/SocialJogger(2643): To stop SNSService
07-19 11:08:12.150: I/SocialJogger(2643): SNSService is already stopped
07-19 11:08:12.150: I/SocialJogger(2643): SNSService onDestroy
07-19 11:08:12.150: I/AlarmManager(131): Alarm type : 3, from setRepeating operation : com.acer.ap.sns
07-19 11:08:12.160: I/SocialJogger(2643): CachedImageService onUnbind
07-19 11:08:12.160: I/SocialJogger(2643): CachedImageService onDestroy
07-19 11:08:12.160: I/ActivityManager(131): No longer want com.android.defcontainer (pid 2326): hidden #16
07-19 11:08:12.200: D/dalvikvm(2643): GC_CONCURRENT freed 188K, 5% free 6597K/6919K, paused 5ms+2ms

I get the same issue with my XperiaPlay in 2.3.4, the app get ANR and crash,: 

07-19 10:59:06.534: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 99ms
07-19 10:59:06.534: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:06.534: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 24-byte allocation
07-19 10:59:06.644: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:06.644: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 99ms
07-19 10:59:06.644: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:06.644: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 24-byte allocation
07-19 10:59:06.664: W/dalvikvm-heap(15111): Attempted recursive GC
07-19 10:59:06.664: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:06.664: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 24-byte allocation
07-19 10:59:06.774: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:06.774: D/dalvikvm(15111): GC_CONCURRENT freed <1K, 16% free 13127K/15559K, external 17261K/19309K, paused 2ms+2ms
07-19 10:59:06.874: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:06.874: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 100ms
07-19 10:59:06.874: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:06.874: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 28-byte allocation
07-19 10:59:06.984: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:06.984: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 99ms
07-19 10:59:06.984: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:06.984: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 8-byte allocation
07-19 10:59:07.084: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.084: D/dalvikvm(15111): GC_FOR_MALLOC freed <1K, 16% free 13127K/15559K, external 17261K/19309K, paused 100ms
07-19 10:59:07.084: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:07.084: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 24-byte allocation
07-19 10:59:07.184: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.184: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 99ms
07-19 10:59:07.184: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:07.184: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 24-byte allocation
07-19 10:59:07.314: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.314: D/dalvikvm(15111): GC_CONCURRENT freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 2ms+2ms
07-19 10:59:07.414: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.414: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 99ms
07-19 10:59:07.414: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:07.414: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 28-byte allocation
07-19 10:59:07.524: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.524: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 99ms
07-19 10:59:07.524: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:07.524: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 24-byte allocation
07-19 10:59:07.634: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.634: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 99ms
07-19 10:59:07.634: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:07.634: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 20-byte allocation
07-19 10:59:07.654: W/dalvikvm-heap(15111): Attempted recursive GC
07-19 10:59:07.654: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:07.654: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 12-byte allocation
07-19 10:59:07.754: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.754: D/dalvikvm(15111): GC_CONCURRENT freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 1ms+2ms
07-19 10:59:07.854: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.854: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 100ms
07-19 10:59:07.854: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:07.854: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 28-byte allocation
07-19 10:59:07.964: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:07.964: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 99ms
07-19 10:59:07.964: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:07.964: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 8-byte allocation
07-19 10:59:08.064: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:08.064: D/dalvikvm(15111): GC_FOR_MALLOC freed <1K, 16% free 13127K/15559K, external 17261K/19309K, paused 100ms
07-19 10:59:08.064: I/dalvikvm-heap(15111): Clamp target GC heap from 32.003MB to 32.000MB
07-19 10:59:08.064: I/dalvikvm-heap(15111): Grow heap (frag case) to 32.000MB for 20-byte allocation
07-19 10:59:08.174: I/dalvikvm-heap(15111): Clamp target GC heap from 34.003MB to 32.000MB
07-19 10:59:08.174: D/dalvikvm(15111): GC_FOR_MALLOC freed 0K, 16% free 13127K/15559K, external 17261K/19309K, paused 100ms

More over when I move on the map, sometimes it crash beacause of huge memory allocation (262144 byte): (here tested with the French map of openAndroMap http://www.openandromaps.org/en/downloads/europe)

07-19 11:03:33.884: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 32K, 66% free 5195K/15111K, external 17517K/19309K, paused 36ms
07-19 11:03:33.934: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 32K, 66% free 5195K/15111K, external 17517K/19309K, paused 35ms
07-19 11:03:33.994: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 32K, 66% free 5195K/15111K, external 17517K/19309K, paused 35ms
07-19 11:03:34.644: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 339K, 67% free 5106K/15111K, external 17517K/19309K, paused 39ms
07-19 11:03:34.904: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 392K, 66% free 5161K/15111K, external 17517K/19309K, paused 40ms
07-19 11:03:35.084: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 166K, 67% free 5035K/15111K, external 17517K/19309K, paused 35ms
07-19 11:03:35.154: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 32K, 67% free 5036K/15111K, external 17517K/19309K, paused 39ms
07-19 11:03:35.214: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 33K, 67% free 5035K/15111K, external 17517K/19309K, paused 34ms
07-19 11:03:35.264: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 32K, 67% free 5034K/15111K, external 17517K/19309K, paused 33ms
07-19 11:03:35.314: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 32K, 67% free 5034K/15111K, external 17517K/19309K, paused 33ms
07-19 11:03:35.364: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 32K, 67% free 5034K/15111K, external 17517K/19309K, paused 34ms
07-19 11:03:35.414: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 32K, 67% free 5034K/15111K, external 17517K/19309K, paused 33ms
07-19 11:03:35.714: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 946K, 63% free 5613K/15111K, external 17517K/19309K, paused 48ms
07-19 11:03:36.004: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 612K, 67% free 5040K/15111K, external 17517K/19309K, paused 42ms
07-19 11:03:36.154: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 279K, 67% free 5137K/15111K, external 17517K/19309K, paused 38ms
07-19 11:03:36.194: D/dalvikvm(15331): GC_EXTERNAL_ALLOC freed 1K, 66% free 5171K/15111K, external 17517K/19309K, paused 39ms
07-19 11:03:36.214: E/dalvikvm-heap(15331): 262144-byte external allocation too large for this process.
07-19 11:03:36.214: E/GraphicsJNI(15331): VM won't let us allocate 262144 bytes
07-19 11:03:36.244: D/dalvikvm(15331): GC_FOR_MALLOC freed <1K, 66% free 5171K/15111K, external 17517K/19309K, paused 26ms
07-19 11:03:36.254: D/skia(15331): --- decoder->decode returned false
07-19 11:03:36.254: W/dalvikvm(15331): threadid=9: thread exiting with uncaught exception (group=0x2aac8578)
07-19 11:03:36.254: E/AndroidRuntime(15331): FATAL EXCEPTION: LayerManager
07-19 11:03:36.254: E/AndroidRuntime(15331): java.lang.OutOfMemoryError: bitmap size exceeds VM budget
07-19 11:03:36.254: E/AndroidRuntime(15331): at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
07-19 11:03:36.254: E/AndroidRuntime(15331): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:504)
07-19 11:03:36.254: E/AndroidRuntime(15331): at org.mapsforge.map.android.graphics.AndroidBitmap.<init>(AndroidBitmap.java:46)
07-19 11:03:36.254: E/AndroidRuntime(15331): at org.mapsforge.map.android.graphics.AndroidGraphicFactory.createBitmap(AndroidGraphicFactory.java:103)
07-19 11:03:36.254: E/AndroidRuntime(15331): at org.mapsforge.map.layer.cache.FileSystemTileCache.get(FileSystemTileCache.java:100)
07-19 11:03:36.254: E/AndroidRuntime(15331): at org.mapsforge.map.layer.cache.TwoLevelTileCache.get(TwoLevelTileCache.java:61)
07-19 11:03:36.254: E/AndroidRuntime(15331): at org.mapsforge.map.layer.TileLayer.drawParentTileBitmap(TileLayer.java:81)
07-19 11:03:36.254: E/AndroidRuntime(15331): at org.mapsforge.map.layer.TileLayer.draw(TileLayer.java:62)
07-19 11:03:36.254: E/AndroidRuntime(15331): at org.mapsforge.map.layer.LayerManager.doWork(LayerManager.java:91)
07-19 11:03:36.254: E/AndroidRuntime(15331): at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)
07-19 11:03:36.254: W/ActivityManager(240):   Force finishing activity org.mapsforge.applications.android.samples/.BasicMapViewer
07-19 11:03:36.744: D/dalvikvm(15331): GC_CONCURRENT freed 357K, 55% free 6827K/15111K, external 17261K/19309K, paused 2ms+3ms
07-19 11:03:37.174: D/dalvikvm(15331): GC_CONCURRENT freed 310K, 44% free 8496K/15111K, external 17261K/19309K, paused 2ms+4ms
07-19 11:03:37.674: I/dalvikvm(15331): Jit: resizing JitTable from 4096 to 8192
07-19 11:03:37.974: D/dalvikvm(15331): GC_CONCURRENT freed 4433K, 60% free 6111K/15111K, external 17517K/19309K, paused 2ms+4ms
07-19 11:03:38.214: D/dalvikvm(15331): GC_CONCURRENT freed 147K, 47% free 8011K/15111K, external 17261K/19309K, paused 2ms+4ms
07-19 11:03:38.604: D/dalvikvm(15331): GC_CONCURRENT freed 320K, 37% free 9662K/15111K, external 17261K/19309K, paused 2ms+4ms
07-19 11:03:39.254: I/dalvikvm-heap(15331): Clamp target GC heap from 32.396MB to 32.000MB
07-19 11:03:39.264: D/dalvikvm(15331): GC_CONCURRENT freed 376K, 26% free 11225K/15111K, external 17517K/19309K, paused 2ms+4ms
07-19 11:03:39.944: D/dalvikvm(15331): GC_CONCURRENT freed 6281K, 57% free 6599K/15303K, external 17261K/19309K, paused 2ms+4ms
07-19 11:03:40.204: D/dalvikvm(15331): GC_CONCURRENT freed 139K, 45% free 8505K/15303K, external 17261K/19309K, paused 2ms+4ms
07-19 11:03:40.544: D/dalvikvm(15331): GC_CONCURRENT freed 249K, 34% free 10217K/15303K, external 17261K/19309K, paused 2ms+3ms
07-19 11:03:41.024: I/dalvikvm-heap(15331): Clamp target GC heap from 32.814MB to 32.000MB
07-19 11:03:41.024: D/dalvikvm(15331): GC_CONCURRENT freed 291K, 23% free 11909K/15303K, external 17261K/19309K, paused 2ms+4ms
07-19 11:03:41.354: I/dalvikvm-heap(15331): Clamp target GC heap from 33.921MB to 32.000MB
07-19 11:03:41.354: D/dalvikvm(15331): GC_CONCURRENT freed 121K, 17% free 13043K/15559K, external 17261K/19309K, paused 2ms+5ms
07-19 11:03:41.504: I/dalvikvm-heap(15331): Clamp target GC heap from 33.983MB to 32.000MB
07-19 11:03:41.504: D/dalvikvm(15331): GC_CONCURRENT freed 5K, 16% free 13106K/15559K, external 17261K/19309K, paused 2ms+5ms
07-19 11:03:41.604: I/dalvikvm-heap(15331): Clamp target GC heap from 33.993MB to 32.000MB
07-19 11:03:41.604: D/dalvikvm(15331): GC_FOR_MALLOC freed 2K, 16% free 13116K/15559K, external 17261K/19309K, paused 99ms
07-19 11:03:41.734: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:41.734: D/dalvikvm(15331): GC_CONCURRENT freed <1K, 16% free 13118K/15559K, external 17261K/19309K, paused 2ms+3ms
07-19 11:03:41.834: I/dalvikvm-heap(15331): Clamp target GC heap from 33.995MB to 32.000MB
07-19 11:03:41.834: D/dalvikvm(15331): GC_FOR_MALLOC freed <1K, 16% free 13118K/15559K, external 17261K/19309K, paused 99ms
07-19 11:03:41.984: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:41.984: D/dalvikvm(15331): GC_CONCURRENT freed <1K, 16% free 13118K/15559K, external 17261K/19309K, paused 1ms+3ms
07-19 11:03:42.084: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.084: D/dalvikvm(15331): GC_FOR_MALLOC freed <1K, 16% free 13119K/15559K, external 17261K/19309K, paused 100ms
07-19 11:03:42.204: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.204: D/dalvikvm(15331): GC_CONCURRENT freed <1K, 16% free 13119K/15559K, external 17261K/19309K, paused 2ms+2ms
07-19 11:03:42.304: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.304: D/dalvikvm(15331): GC_FOR_MALLOC freed <1K, 16% free 13119K/15559K, external 17261K/19309K, paused 100ms
07-19 11:03:42.414: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.414: D/dalvikvm(15331): GC_FOR_MALLOC freed 0K, 16% free 13119K/15559K, external 17261K/19309K, paused 99ms
07-19 11:03:42.414: I/dalvikvm-heap(15331): Forcing collection of SoftReferences for 24-byte allocation
07-19 11:03:42.524: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.524: D/dalvikvm(15331): GC_FOR_MALLOC freed 0K, 16% free 13119K/15559K, external 17261K/19309K, paused 110ms
07-19 11:03:42.524: E/dalvikvm-heap(15331): Out of memory on a 24-byte allocation.
07-19 11:03:42.524: I/dalvikvm(15331): "HeapWorker" daemon prio=5 tid=2 RUNNABLE
07-19 11:03:42.524: I/dalvikvm(15331):   | group="system" sCount=0 dsCount=0 obj=0x2afc2088 self=0x21b0a8
07-19 11:03:42.524: I/dalvikvm(15331):   | sysTid=15332 nice=0 sched=0/0 cgrp=[fopen-error:2] handle=2695832
07-19 11:03:42.524: I/dalvikvm(15331):   at com.android.internal.os.BinderInternal$GcWatcher.finalize(BinderInternal.java:~48)
07-19 11:03:42.524: I/dalvikvm(15331):   at dalvik.system.NativeStart.run(Native Method)
07-19 11:03:42.654: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.654: D/dalvikvm(15331): GC_CONCURRENT freed 0K, 16% free 13119K/15559K, external 17261K/19309K, paused 1ms+2ms
07-19 11:03:42.744: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.744: D/dalvikvm(15331): GC_FOR_MALLOC freed 0K, 16% free 13119K/15559K, external 17261K/19309K, paused 98ms
07-19 11:03:42.744: I/dalvikvm-heap(15331): Forcing collection of SoftReferences for 24-byte allocation
07-19 11:03:42.844: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.844: D/dalvikvm(15331): GC_FOR_MALLOC freed 0K, 16% free 13119K/15559K, external 17261K/19309K, paused 99ms
07-19 11:03:42.844: E/dalvikvm-heap(15331): Out of memory on a 24-byte allocation.
07-19 11:03:42.844: I/dalvikvm(15331): "MapWorker" prio=3 tid=10 RUNNABLE JIT
07-19 11:03:42.844: I/dalvikvm(15331):   | group="main" sCount=0 dsCount=0 obj=0x2b0134b0 self=0x2e6078
07-19 11:03:42.844: I/dalvikvm(15331):   | sysTid=15340 nice=13 sched=3/0 cgrp=[fopen-error:2] handle=3039664
07-19 11:03:42.844: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.scaleLatLong(DatabaseRenderer.java:~377)
07-19 11:03:42.844: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.renderWay(DatabaseRenderer.java:352)
07-19 11:03:42.844: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.processReadMapData(DatabaseRenderer.java:321)
07-19 11:03:42.844: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:152)
07-19 11:03:42.844: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:62)
07-19 11:03:42.844: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:44)
07-19 11:03:42.844: I/dalvikvm(15331):   at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)
07-19 11:03:42.964: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:42.964: D/dalvikvm(15331): GC_FOR_MALLOC freed 0K, 16% free 13119K/15559K, external 17261K/19309K, paused 102ms
07-19 11:03:42.964: I/dalvikvm-heap(15331): Forcing collection of SoftReferences for 24-byte allocation
07-19 11:03:43.064: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:43.064: D/dalvikvm(15331): GC_FOR_MALLOC freed 0K, 16% free 13119K/15559K, external 17261K/19309K, paused 99ms
07-19 11:03:43.064: E/dalvikvm-heap(15331): Out of memory on a 24-byte allocation.
07-19 11:03:43.064: I/dalvikvm(15331): "HeapWorker" daemon prio=5 tid=2 RUNNABLE
07-19 11:03:43.064: I/dalvikvm(15331):   | group="system" sCount=0 dsCount=0 obj=0x2afc2088 self=0x21b0a8
07-19 11:03:43.064: I/dalvikvm(15331):   | sysTid=15332 nice=0 sched=0/0 cgrp=[fopen-error:2] handle=2695832
07-19 11:03:43.064: I/dalvikvm(15331):   at com.android.internal.os.BinderInternal$GcWatcher.finalize(BinderInternal.java:~48)
07-19 11:03:43.064: I/dalvikvm(15331):   at dalvik.system.NativeStart.run(Native Method)
07-19 11:03:43.064: I/dalvikvm(15331): Uncaught exception thrown by finalizer (will be discarded):
07-19 11:03:43.064: I/dalvikvm(15331): Ljava/lang/OutOfMemoryError;: [memory exhausted]
07-19 11:03:43.064: I/dalvikvm(15331): at dalvik.system.NativeStart.main(Native Method)
07-19 11:03:43.174: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:43.174: D/dalvikvm(15331): GC_FOR_MALLOC freed <1K, 16% free 13119K/15559K, external 17261K/19309K, paused 98ms
07-19 11:03:43.174: I/dalvikvm-heap(15331): Forcing collection of SoftReferences for 24-byte allocation
07-19 11:03:43.274: I/dalvikvm-heap(15331): Clamp target GC heap from 33.996MB to 32.000MB
07-19 11:03:43.274: D/dalvikvm(15331): GC_FOR_MALLOC freed 0K, 16% free 13119K/15559K, external 17261K/19309K, paused 99ms
07-19 11:03:43.274: E/dalvikvm-heap(15331): Out of memory on a 24-byte allocation.
07-19 11:03:43.274: I/dalvikvm(15331): "MapWorker" prio=3 tid=10 RUNNABLE JIT
07-19 11:03:43.274: I/dalvikvm(15331):   | group="main" sCount=0 dsCount=0 obj=0x2b0134b0 self=0x2e6078
07-19 11:03:43.274: I/dalvikvm(15331):   | sysTid=15340 nice=13 sched=3/0 cgrp=[fopen-error:2] handle=3039664
07-19 11:03:43.274: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.scaleLatLong(DatabaseRenderer.java:~377)
07-19 11:03:43.274: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.renderWay(DatabaseRenderer.java:352)
07-19 11:03:43.274: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.processReadMapData(DatabaseRenderer.java:321)
07-19 11:03:43.274: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:152)
07-19 11:03:43.274: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:62)
07-19 11:03:43.274: I/dalvikvm(15331):   at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:44)
07-19 11:03:43.274: I/dalvikvm(15331):   at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)
07-19 11:03:43.364: D/dalvikvm(15331): GC_FOR_MALLOC freed 4702K, 46% free 8416K/15559K, external 17261K/19309K, paused 95ms
07-19 11:03:43.364: W/dalvikvm(15331): threadid=10: thread exiting with uncaught exception (group=0x2aac8578)
07-19 11:03:43.364: I/Process(15331): Sending signal. PID: 15331 SIG: 9
07-19 11:03:43.374: I/ActivityManager(240): Process org.mapsforge.applications.android.samples (pid 15331) has died.
07-19 11:03:43.384: D/kernel(120): [32425.996154] binder: release 15331:15339 transaction 1692225 out, still active
07-19 11:03:43.384: D/kernel(120): [32425.996826] binder: 240:240 transaction failed 29189, size 56-0

Is this normal? Or do you have a more stable version of rewrite branch?

Regards.

Max

[Maxime Guyon]

More over this was without any rotation.

On the Iconia Tab and Germany map, when I rotate the tablet I get always an OOM with big memory allocation (8017936-byte allocation):

07-19 11:36:20.360: I/ActivityManager(131): Config changed: {1.0 0mcc0mnc fr_FR sw800dp w1280dp h752dp xlrg land finger -keyb/v/h -nav/h s.6}
07-19 11:36:20.440: I/MusicA(1647): updateWidget() ) --- int displayID = -1
07-19 11:36:20.450: D/HAL(3064): [HAL] hw_get_module:share library path:/system/lib/hw/gralloc.tegra.so
07-19 11:36:20.480: D/dalvikvm(3064): GC_FOR_ALLOC freed 8628K, 30% free 24834K/35335K, paused 31ms
07-19 11:36:20.490: I/dalvikvm-heap(3064): Grow heap (frag case) to 31.998MB for 8017936-byte allocation
07-19 11:36:20.530: D/dalvikvm(3064): GC_CONCURRENT freed 0K, 25% free 32664K/43207K, paused 1ms+3ms
07-19 11:36:20.560: D/dalvikvm(3064): GC_FOR_ALLOC freed 2K, 25% free 32661K/43207K, paused 27ms
07-19 11:36:20.560: I/dalvikvm-heap(3064): Forcing collection of SoftReferences for 8017936-byte allocation
07-19 11:36:20.590: D/dalvikvm(3064): GC_BEFORE_OOM freed 12K, 25% free 32648K/43207K, paused 33ms
07-19 11:36:20.590: E/dalvikvm-heap(3064): Out of memory on a 8017936-byte allocation.
07-19 11:36:20.590: I/dalvikvm(3064): "main" prio=5 tid=1 RUNNABLE
07-19 11:36:20.590: I/dalvikvm(3064):   | group="main" sCount=0 dsCount=0 obj=0x40162600 self=0x12620

[Marcus Schmidke]

Ludwig,

since July 1st, is there anything new about your research? Your experiments sounded to be successful. Will your changes be checked in to the main mapsforge rewrite branch? Or shall I try your patch?

Any help to get around the memory exceptions in rewrite branch will be appreciated, since going back to master branch would be too much change in my code.

Marcus.

[Ludwig]

Hi there,

thanks for your interest in this. I have not done any further research into this as I think the suggested changes work. Technically, it is still possible to create OOM situations with aggressive testing, particularly on emulators, but I do not think they appear with any frequency on real devices.

The changes suggested were an implementation of what Google recommended and a similar fix has long been applied to the master branch. If you discover any issues, please report back.

Ludwig

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/459b304b-a211-4537-be19-54127a9a0b5d%40googlegroups.com.

[Marcus Schmidke]

Hi Ludwig,

thank you for your reply! 

Unfortunately, I'm mainly interested in the rewrite branch since using the master branch would cause too much code changes in my app.

Using the last successful build of rewrite branch (from ci server) still has the "bitmap size" problem. Against which branch did you do your research? Since the Subject says "rewrite", I was hoping you were talking about rewrite branch. If so, is there a chance to get a version of rewrite branch including your fix?

Marcus.

[Ludwig]

I think you misunderstood what I tried to say, apologies if I was not clear.

As previously announced on this thread, my suggested changes are at http://code.google.com/r/ludwigbrinckmann-mapsforge/source/list?name=rewrite-memory

They have not been integrated into the rewrite branch and are based on slightly older version of the rewrite branch, but merging this should not be too difficult.

Ludwig

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/44b0bf80-8c9f-4371-b16c-78a3ce99237b%40googlegroups.com.