not able to extract tex from large pdfs - android

I am reading pdf using itext on android platform and i'm using the following code.but when i try to open large pdfs it gives out of memory error on first line i.e. reader = new PdfReader(fileName);.Also below is the satck trace generated when a large file is clicked.
reader = new PdfReader(fileName);
numberOfPages = reader.getNumberOfPages();
System.out.println("This document contains:" + numberOfPages);
extractor = new PdfTextExtractor(reader);
01-23 18:04:50.607: INFO/System.out(428): ####!!!/sdcard/Moby_Dick_NT.pdf
external 899K/1038K, paused 202ms
01-23 18:05:31.298: INFO/dalvikvm(428): Jit: resizing JitTable from 1024 to 2048
01-23 18:05:32.947: DEBUG/dalvikvm(428): GC_FOR_MALLOC freed 1678K, 31% free 10361K/14855K, external 899K/1038K, paused 218ms
01-23 18:05:35.657: DEBUG/dalvikvm(428): GC_CONCURRENT freed 2038K, 31% free 10403K/15047K, external 899K/1038K, paused 5ms+10ms
01-23 18:06:00.537: DEBUG/dalvikvm(428): GC_CONCURRENT freed 1845K, 30% free 10625K/15111K, external 899K/1038K, paused 9ms+8ms
01-23 18:06:02.397: DEBUG/dalvikvm(428): GC_FOR_MALLOC freed 1995K, 32% free 10546K/15303K, external 899K/1038K, paused 259ms
01-23 18:06:04.518: DEBUG/dalvikvm(428): GC_CONCURRENT freed 1993K, 32% free 10545K/15303K, external 899K/1038K, paused 9ms+5ms
01-23 18:06:06.468: DEBUG/dalvikvm(428): GC_CONCURRENT freed 1917K, 31% free 10583K/15303K, external 899K/1038K, paused 9ms+5ms
01-23 18:06:08.008: INFO/dalvikvm-heap(428): Clamp target GC heap from 16.145MB to 16.000MB
01-23 18:06:08.008: DEBUG/dalvikvm(428): GC_CONCURRENT freed 1542K, 29% free 10981K/15303K, external 899K/1038K, paused 9ms+5ms
browse.com/.PDFView}
01-23 18:06:09.338: INFO/dalvikvm-heap(428): Clamp target GC heap from 16.498MB to 16.000MB
01-23 18:06:09.338: DEBUG/dalvikvm(428): GC_FOR_MALLOC freed 1370K, 27% free 11342K/15495K, external 899K/1038K, paused 243ms
01-23 18:06:10.437: INFO/dalvikvm-heap(428): Clamp target GC heap from 16.776MB to 16.000MB
01-23 18:06:10.437: DEBUG/dalvikvm(428): GC_FOR_MALLOC freed 1079K, 25% free 11627K/15495K, external 899K/1038K, paused 228ms
01-23 18:06:10.857: INFO/dalvikvm-heap(428): Clamp target GC heap from 16.841MB to 16.000MB
01-23 18:06:10.857: DEBUG/dalvikvm(428): GC_FOR_MALLOC freed 256K, 25% free 11694K/15495K, external 899K/1038K, paused 215ms
01-23 18:06:10.867: INFO/dalvikvm-heap(428): Forcing collection of SoftReferences for 4100-byte allocation
01-23 18:06:11.137: INFO/dalvikvm-heap(428): Clamp target GC heap from 16.827MB to 16.000MB
01-23 18:06:11.137: DEBUG/dalvikvm(428): GC_FOR_MALLOC freed 15K, 25% free 11679K/15495K, external 899K/1038K, paused 272ms
01-23 18:06:11.137: ERROR/dalvikvm-heap(428): Out of memory on a 4100-byte allocation.
01-23 18:06:11.147: INFO/dalvikvm(428): "main" prio=5 tid=1 RUNNABLE
01-23 18:06:11.147: INFO/dalvikvm(428): | group="main" sCount=0 dsCount=0 obj=0x4001f1a8 self=0xce48

There is a related discussion about memory allocation in another thread here on SO:
Android memory allocation
Haven't tried it myself but it might be worthwhile to try the option
android:largeHeap="true"
in the manifest since its hitting the 16MB upper boundary.

Related

How to avoid GC overhead in Android when using media like Images?

I am creating Image apps which has over 4k images. I dont load images as required rather load when required however if user visits different parts of app which links to different images my app becomes slow and waits for GC to run which makes it bad user experience.
I saw logcat with following messages:
10-08 14:21:26.249: D/dalvikvm(31547): GC_FOR_ALLOC freed 1677K, 13% free 14097K/16124K, paused 29ms, total 29ms
10-08 14:21:26.749: D/dalvikvm(31547): GC_FOR_ALLOC freed 1711K, 13% free 14092K/16124K, paused 28ms, total 28ms
10-08 14:21:27.610: D/dalvikvm(31547): GC_FOR_ALLOC freed 1694K, 13% free 14103K/16124K, paused 29ms, total 29ms
10-08 14:21:29.592: D/dalvikvm(31547): GC_FOR_ALLOC freed 1729K, 13% free 14081K/16124K, paused 32ms, total 32ms
10-08 14:21:30.874: D/dalvikvm(31547): GC_FOR_ALLOC freed 1675K, 13% free 14102K/16124K, paused 30ms, total 30ms
10-08 14:21:32.435: D/dalvikvm(31547): GC_FOR_ALLOC freed 1735K, 13% free 14075K/16124K, paused 33ms, total 33ms
10-08 14:21:34.017: D/dalvikvm(31547): GC_FOR_ALLOC freed 1629K, 13% free 14145K/16124K, paused 28ms, total 29ms
10-08 14:21:35.098: D/dalvikvm(31547): GC_FOR_ALLOC freed 1774K, 13% free 14093K/16124K, paused 29ms, total 29ms
10-08 14:21:36.290: D/dalvikvm(31547): GC_FOR_ALLOC freed 1703K, 13% free 14094K/16124K, paused 29ms, total 29ms
10-08 14:21:37.991: D/dalvikvm(31547): GC_FOR_ALLOC freed 1722K, 13% free 14077K/16124K, paused 27ms, total 28ms
10-08 14:21:39.213: D/dalvikvm(31547): GC_FOR_ALLOC freed 1693K, 13% free 14083K/16124K, paused 28ms, total 28ms
10-08 14:21:41.175: D/dalvikvm(31547): GC_FOR_ALLOC freed 1696K, 13% free 14088K/16124K, paused 28ms, total 28ms
I tried to improve/optimize my code by doing following changes:
Everytime I load app I clear my cached images.
Implemented ViewHolder pattern for ListViews.
Used android:largeHeap="true" attribute in Manifest at Application tag level.
Made classes which are used frequently to do some operations singleton.
But still not able to achieve performance i need.
I used Universal Image Loader Library which has cache mechanism but still its runs GC.
How to avoid GC or what are other optimization techniques.

Why the GC happens so frequent in Android?

I have exit my app, but there is still a backgroud service is running. Whe the GC logs come a log. I will so you the logs beblow. You can see, about 3 logs per second. Is This phenomenon is normal ? My device's memory is enough, and the backgroud service is holding a WebSocket connection.
08-11 10:33:54.456 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 12ms+6ms, total 44ms
08-11 10:33:54.776 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1985K, 18% free 10676K/12871K, paused 12ms+8ms, total 54ms
08-11 10:33:55.109 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1950K, 18% free 10671K/12871K, paused 12ms+17ms, total 68ms
08-11 10:33:55.459 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2004K, 18% free 10680K/12871K, paused 13ms+8ms, total 62ms
08-11 10:33:55.769 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2010K, 18% free 10680K/12871K, paused 12ms+7ms, total 48ms
08-11 10:33:56.093 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1996K, 18% free 10677K/12871K, paused 12ms+9ms, total 50ms
08-11 10:33:56.416 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2028K, 18% free 10681K/12871K, paused 2ms+8ms, total 37ms
08-11 10:33:56.746 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2031K, 18% free 10682K/12871K, paused 8ms+8ms, total 46ms
08-11 10:33:57.079 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1996K, 18% free 10677K/12871K, paused 12ms+7ms, total 46ms
08-11 10:33:57.429 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2002K, 18% free 10678K/12871K, paused 12ms+19ms, total 59ms
08-11 10:33:57.766 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2003K, 18% free 10679K/12871K, paused 12ms+7ms, total 46ms
08-11 10:33:58.143 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1945K, 18% free 10669K/12871K, paused 12ms+17ms, total 72ms
08-11 10:33:58.473 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 2ms+6ms, total 41ms
08-11 10:33:58.786 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2013K, 17% free 10690K/12871K, paused 12ms+8ms, total 48ms
08-11 10:33:59.106 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2031K, 18% free 10683K/12871K, paused 12ms+8ms, total 53ms
08-11 10:33:59.443 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2021K, 18% free 10681K/12871K, paused 12ms+8ms, total 48ms
08-11 10:33:59.786 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2028K, 18% free 10681K/12871K, paused 11ms+7ms, total 44ms
08-11 10:34:00.153 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1997K, 18% free 10677K/12871K, paused 12ms+18ms, total 58ms
Is This phenomenon is normal ?
It depends what you mean by "normal".
If you mean normal for an application with those particular heap dimensions, that amount of heapspace used for long-lived objects, and that rate of allocation ... then the answer is "Yes, it is normal".
Basically, you are running your application with a heap that is (objectively) too small for the work that you are asking it to do. You have roughly 2Mb of free space, and you are allocating objects at roughly 6Gb per second. If you want to reduce the number of GC cycles, you need to do one or more of the following:
Increase the heap size. (I don't know if this is feasible for an Android app ...)
Reduce the "working set" of long-lived objects. Maybe you have a memory leak, lots of large images loaded, or an overly large in-memory cache of ... something.
Reduce the rate at which new objects are being allocated by your application.
The last two require you to track down the source of the memory usage / allocation, and change you code to mitigate the effects. There are tools (memory profilers) that can help with this, but the details will be specific to your application.
Here's how I'd interpret the GC log lines ... by example:
08-11 10:33:54.456 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕
GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 12ms+6ms, total 44ms
The "GC_CONCURRENT" collector is being used.
This GC collection cycle reclaimed 2020K bytes.
When the GC cycle completed, 18% of the heap is free, and 10682K out of a total usable heap size of 12871K is in use.
Normal thread activity was paused for two intervals of 12ms and 6ms respectively.
The elapsed time for the GC cycle was 44ms.
Note that the amount of heap freed isn't always exactly the same as the different between total and available ... because for much of the time that the GC is running there are normal threads allocating new objects.

Where to store description data for markers to avoid outofmemory errors?

I have 1700 markers with strings holding a description for each marker on the map. I am getting the out of memory error since I am holding so many strings for each markers "click for more info" next screen activity. How can I better hold this data and share it on marker click and not have this memory issue? I am pulling my data from an XML based file.
Here is my error log after crash:
10-07 13:42:55.383: D/dalvikvm(4431): GC_FOR_MALLOC freed 1063K, 57% free 9611K/21959K, external 2506K/2804K, paused 77ms
10-07 13:42:57.109: D/dalvikvm(4431): GC_FOR_MALLOC freed 1580K, 56% free 9821K/21959K, external 2551K/2804K, paused 114ms
10-07 13:42:57.320: D/dalvikvm(4431): GC_FOR_MALLOC freed 427K, 55% free 10016K/21959K, external 2365K/2804K, paused 97ms
10-07 13:42:57.656: D/dalvikvm(4431): GC_FOR_MALLOC freed 168K, 54% free 10142K/21959K, external 2365K/2804K, paused 166ms
10-07 13:42:57.804: D/dalvikvm(4431): GC_FOR_MALLOC freed 118K, 54% free 10218K/21959K, external 2365K/2804K, paused 85ms
10-07 13:42:57.922: D/dalvikvm(4431): GC_FOR_MALLOC freed 47K, 54% free 10320K/21959K, external 2365K/2804K, paused 71ms
10-07 13:42:58.031: D/dalvikvm(4431): GC_FOR_MALLOC freed 119K, 54% free 10297K/21959K, external 2365K/2804K, paused 70ms
10-07 13:42:58.148: D/dalvikvm(4431): GC_FOR_MALLOC freed 51K, 53% free 10342K/21959K, external 2365K/2804K, paused 69ms
10-07 13:42:58.148: I/dalvikvm-heap(4431): Grow heap (frag case) to 14.855MB for 33642-byte allocation
10-07 13:42:58.226: D/dalvikvm(4431): GC_FOR_MALLOC freed <1K, 53% free 10375K/22023K, external 2365K/2804K, paused 77ms
10-07 13:42:58.328: D/dalvikvm(4431): GC_FOR_MALLOC freed 83K, 54% free 10343K/22023K, external 2365K/2804K, paused 73ms
10-07 13:42:58.336: I/dalvikvm-heap(4431): Grow heap (frag case) to 14.863MB for 40183-byte allocation
10-07 13:42:58.406: D/dalvikvm(4431): GC_FOR_MALLOC freed 0K, 53% free 10383K/22087K, external 2365K/2804K, paused 72ms
10-07 13:42:58.476: D/dalvikvm(4431): GC_FOR_MALLOC freed 42K, 54% free 10379K/22087K, external 2365K/2804K, paused 71ms
10-07 13:42:58.609: D/dalvikvm(4431): GC_FOR_MALLOC freed 62K, 53% free 10381K/22087K, external 2365K/2804K, paused 78ms
10-07 13:42:58.750: D/dalvikvm(4431): GC_FOR_MALLOC freed 44K, 53% free 10421K/22087K, external 2365K/2804K, paused 79ms
10-07 13:42:58.758: I/dalvikvm-heap(4431): Grow heap (frag case) to 15.005MB for 111024-byte allocation
10-07 13:42:58.844: D/dalvikvm(4431): GC_FOR_MALLOC freed <1K, 53% free 10529K/22215K, external 2365K/2804K, paused 75ms
10-07 13:42:58.961: D/dalvikvm(4431): GC_EXTERNAL_ALLOC freed 10K, 53% free 10528K/22215K, external 2365K/2804K, paused 111ms
10-07 13:42:58.992: E/dalvikvm-heap(4431): 32-byte external allocation too large for this process.
10-07 13:42:58.992: W/OSMemory(4431): External allocation of 32 bytes was rejected
10-07 13:42:59.070: D/dalvikvm(4431): GC_FOR_MALLOC freed 0K, 53% free 10528K/22215K, external 2365K/2804K, paused 68ms
10-07 13:42:59.187: D/dalvikvm(4431): GC_FOR_MALLOC freed 32K, 53% free 10535K/22215K, external 2365K/2804K, paused 69ms
10-07 13:42:59.187: I/dalvikvm-heap(4431): Forcing collection of SoftReferences for 40194-byte allocation
10-07 13:42:59.250: D/dalvikvm(4431): GC_FOR_MALLOC freed <1K, 53% free 10534K/22215K, external 2365K/2804K, paused 67ms
10-07 13:42:59.258: E/dalvikvm-heap(4431): Out of memory on a 40194-byte allocation.
10-07 13:42:59.258: I/dalvikvm(4431): "its_ter" prio=5 tid=13 RUNNABLE
10-07 13:42:59.258: I/dalvikvm(4431): | group="main" sCount=0 dsCount=0 obj=0x4058b398 self=0xfcfe0
10-07 13:42:59.258: I/dalvikvm(4431): | sysTid=4443 nice=10 sched=0/0 cgrp=bg_non_interactive handle=1036568
10-07 13:42:59.258: I/dalvikvm(4431): at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:~122)
10-07 13:42:59.258: I/dalvikvm(4431): at maps.m.y.a((null):-1)
10-07 13:42:59.258: I/dalvikvm(4431): at maps.k.d.a((null):-1)
10-07 13:42:59.258: I/dalvikvm(4431): at maps.k.g.handleMessage((null):-1)
10-07 13:42:59.265: I/dalvikvm(4431): at android.os.Handler.dispatchMessage(Handler.java:99)
10-07 13:42:59.281: I/dalvikvm(4431): at android.os.Looper.loop(Looper.java:130)
10-07 13:42:59.281: I/dalvikvm(4431): at maps.k.d.c((null):-1)
10-07 13:42:59.281: I/dalvikvm(4431): at maps.ao.b.run((null):-1)
10-07 13:42:59.289: W/System.err(4431): OutOfMemory
10-07 13:42:59.429: D/dalvikvm(4431): GC_EXPLICIT freed 32K, 53% free 10567K/22215K, external 2365K/2804K, paused 128ms
10-07 13:42:59.539: D/dalvikvm(4431): GC_FOR_MALLOC freed 435K, 54% free 10235K/22215K, external 2365K/2804K, paused 75ms
10-07 13:42:59.539: I/dalvikvm-heap(4431): Forcing collection of SoftReferences for 119952-byte allocation
10-07 13:42:59.633: D/dalvikvm(4431): GC_FOR_MALLOC freed 111K, 55% free 10123K/22215K, external 2365K/2804K, paused 97ms
10-07 13:42:59.734: D/dalvikvm(4431): GC_EXTERNAL_ALLOC freed 2K, 54% free 10241K/22215K, external 2365K/2804K, paused 85ms
10-07 13:42:59.765: E/dalvikvm-heap(4431): 32-byte external allocation too large for this process.
10-07 13:42:59.765: W/OSMemory(4431): External allocation of 32 bytes was rejected
10-07 13:42:59.844: D/dalvikvm(4431): GC_FOR_MALLOC freed 0K, 54% free 10241K/22215K, external 2365K/2804K, paused 69ms
10-07 13:42:59.890: W/dalvikvm(4431): threadid=13: thread exiting with uncaught exception (group=0x40015560)
10-07 13:42:59.914: W/dalvikvm(4431): threadid=20: thread exiting with uncaught exception (group=0x40015560)
10-07 13:42:59.922: I/Process(4431): Sending signal. PID: 4431 SIG: 9
I am posting them on the map like so:
BitmapDescriptor icon = BitmapDescriptorFactory
.fromResource(R.drawable.snotel_marker);
int nsize = visibleMarkers.size();
for (int i = 0; i < nsize; i++) {
MapMarkers marks = new MapMarkers();
String title = visibleMarkers.valueAt(i).getTitle();
String desc = visibleMarkers.valueAt(i).getDesc();
Float latitude = visibleMarkers.valueAt(i).getLat();
Float longitude = visibleMarkers.valueAt(i).getLon();
m = map.addMarker(new MarkerOptions()
.position(new LatLng(latitude, longitude))
.title(title).icon(icon));
marks.setTitle(title);
marks.setDesc(desc);
m.setData(marks);
On Info Window Click the next activity is populated like so:
getSupportActionBar().setTitle(extras.getString("name"));
webview.loadDataWithBaseURL(null, extras.getString("description"),
"text/html", "utf-8", null);
The app runs fine on my GNex, but on my old Droid, it populates the map, then after clicking on 3 or 4 markers and moving the map around I get the out of memory error. Any other output I can share to try and figure this out?
EDIT heap dump from MAT - String is the issue according to this:
Problem Suspect 1
9,566 instances of "java.lang.String", loaded by "<system class loader>" occupy 2,299,848 (34.18%) bytes.
Keywords
java.lang.String
Details »
Problem Suspect 2
3,381 instances of "java.lang.Class", loaded by "<system class loader>" occupy 960,088 (14.27%) bytes.
Biggest instances:
•class android.text.Html$HtmlParser # 0x4018c9d0 - 126,632 (1.88%) bytes.
Keywords
java.lang.Class
Details »

external allocation too large for this process, android

in my simple app i am using 6 buttons and setting background with png.
Button btnGadgetmusic = (Button) findViewById(R.id.gadgetmusic);
btnGadgetmusic.setBackgroundResource(R.drawable.btnselectedsong);
minimum size of png is 13.5K and maximum size is 40K. When ever i try to run this app on emulator with version 2.3, i get "external allocation too large for this process" and interestningly if i run on honeycomb or on ICS then there is no problem.
So i am confused what should i do, should i ignore it, if not, do we have some better solution for that.
looking for your reply
EDIT Log File added
I/dalvikvm-heap(4190): Clamp target GC heap from 25.494MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed <1K, 51% free 2647K/5379K, external 18806K/20812K, paused 28ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed <1K, 51% free 2647K/5379K, external 18806K/20812K, paused 49ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.833MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 51% free 2647K/5379K, external 19153K/20812K, paused 25ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed <1K, 51% free 2657K/5379K, external 19153K/20812K, paused 56ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.852MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed <1K, 51% free 2657K/5379K, external 19162K/20812K, paused 24ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed 4K, 51% free 2671K/5379K, external 19162K/20812K, paused 69ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.887MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 51% free 2671K/5379K, external 19184K/20812K, paused 28ms
W/KeyCharacterMap(4190): No keyboard for id 0
W/KeyCharacterMap(4190): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
W/KeyCharacterMap(4190): No keyboard for id 0
W/KeyCharacterMap(4190): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
I/dalvikvm-heap(4190): Clamp target GC heap from 25.913MB to 24.000MB
D/dalvikvm(4190): GC_CONCURRENT freed 16K, 50% free 2697K/5379K, external 19184K/20812K, paused
3ms+35ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.942MB to 24.000MB
D/dalvikvm(4190): GC_CONCURRENT freed 13K, 50% free 2727K/5379K, external 19184K/20812K, paused 3ms+3ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed 2K, 50% free 2724K/5379K, external 19184K/20812K, paused 65ms
E/dalvikvm-heap(4190): 20736-byte external allocation too large for this process.
I/dalvikvm-heap(4190): Clamp target GC heap from 25.939MB to 24.000MB
E/GraphicsJNI(4190): VM won't let us allocate 20736 bytes
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 50% free 2724K/5379K, external 19184K/20812K, paused 38ms
D/skia(4190): --- decoder->decode returned false
D/AndroidRuntime(4190): Shutting down VM
W/dalvikvm(4190): threadid=1: thread exiting with uncaught exception (group=0x40015560)
E/AndroidRuntime(4190): FATAL EXCEPTION: main
E/AndroidRuntime(4190): java.lang.OutOfMemoryError: bitmap size exceeds VM budget

Heap keeps increasing in Google Map API V2

I have got a problem which is driving me wild. I used Google Map API V2 in my Code and when I'm moving the map I can see the following Logcat output (on Nexus 7):
01-23 21:17:10.724: D/dalvikvm(5484): GC_FOR_ALLOC freed 4531K, 21% free 12911K/16312K, paused 29ms, total 29ms
01-23 21:17:10.724: I/dalvikvm-heap(5484): Grow heap (frag case) to 13.043MB for 285724-byte allocation
01-23 21:17:10.744: D/dalvikvm(5484): GC_FOR_ALLOC freed 200K, 22% free 12990K/16592K, paused 25ms, total 25ms
01-23 21:17:12.074: D/dalvikvm(5484): GC_FOR_ALLOC freed 1326K, 23% free 12893K/16592K, paused 30ms, total 31ms
01-23 21:18:04.854: D/dalvikvm(5484): Debugger has detached; object registry had 1 entries
01-23 21:18:07.374: D/dalvikvm(5484): GC_FOR_ALLOC freed 658K, 23% free 12904K/16592K, paused 27ms, total 27ms
01-23 21:18:07.384: I/dalvikvm-heap(5484): Grow heap (frag case) to 13.763MB for 1048592-byte allocation
01-23 21:18:07.404: D/dalvikvm(5484): GC_FOR_ALLOC freed 2K, 21% free 13925K/17620K, paused 27ms, total 27ms
01-23 21:18:07.714: D/dalvikvm(5484): GC_FOR_ALLOC freed 2127K, 26% free 13054K/17620K, paused 29ms, total 29ms
01-23 21:18:44.694: D/dalvikvm(5484): GC_CONCURRENT freed 1894K, 27% free 12970K/17620K, paused 4ms+5ms, total 56ms
01-23 21:18:46.684: D/dalvikvm(5484): GC_CONCURRENT freed 1738K, 27% free 12996K/17620K, paused 4ms+2ms, total 53ms
01-23 21:18:49.254: D/dalvikvm(5484): GC_CONCURRENT freed 1756K, 27% free 13014K/17620K, paused 2ms+8ms, total 77ms
01-23 21:18:56.864: I/dalvikvm(5484): Jit: resizing JitTable from 8192 to 16384
01-23 21:18:56.934: D/dalvikvm(5484): GC_CONCURRENT freed 1840K, 21% free 13010K/16312K, paused 2ms+4ms, total 49ms
01-23 21:18:59.434: D/dalvikvm(5484): GC_CONCURRENT freed 1779K, 21% free 12995K/16312K, paused 4ms+5ms, total 50ms
01-23 21:19:03.414: D/dalvikvm(5484): GC_CONCURRENT freed 1781K, 21% free 13007K/16312K, paused 2ms+3ms, total 48ms
The heap keeps growing and growing and I have no idea what I can do about it. I searched through the web and through stackoverflow, but there was no helpful answer for me.
I hope someone of you can find the error. I am very new to Android, so please appreciate.
EDIT1: Heap Dump:
EDIT2: MAT Analysis
Suspect 1:
One instance of "maps.by.a" loaded by "dalvik.system.PathClassLoader # 0x4480cfa8" occupies 1.002.352 (22,33%) bytes. The memory is accumulated in one instance of "maps.by.d" loaded by "dalvik.system.PathClassLoader # 0x4480cfa8".
Keywords
maps.by.a
dalvik.system.PathClassLoader # 0x4480cfa8
maps.by.d
Suspect 2:
3.507 instances of "java.lang.Class", loaded by "<system class loader>" occupy 795.104 (17,72%) bytes.
Biggest instances:
•class com.ibm.icu4jni.util.Resources$DefaultTimeZones # 0x401fccc8 - 151.744 (3,38%) bytes.
•class android.text.Html$HtmlParser # 0x4016d288 - 126.592 (2,82%) bytes.
•class org.apache.harmony.security.fortress.Services # 0x40091188 - 51.456 (1,15%) bytes.
Keywords
java.lang.Class
Suspect 3:
8.168 instances of "java.lang.String", loaded by "<system class loader>" occupy 529.048 (11,79%) bytes.
Keywords
java.lang.String
First, your heap doesn't "keep growing". It is hovering between 12893K and 13054K, rising and falling, with one outlier peak at 13925K. Personally, I don't see anything in that log that would worry me.
Regarding your MAT output, if those are the three top culprits, none are surprising. The latter two say "I am writing an app for Android", as those are always there on any Android app. The first one indicates that Maps V2 has one rather pudgy object. Again, I see nothing in that output that would suggest a problem.

Categories

Resources