I'm getting a flood of GC_CONCURRENT freed messages in LogCat and they are not coming from my own app (I force closed my app to be sure). The memory freed is very consistent (about 1430K) and it occurs about 6 times per second.
How can I troubleshoot this?
It's interfering with my app development because it floods LogCat and forces valuable log statements out of the buffer and also causes LogCat to "jiggle" because the session filter jumps up and down one line each time a GC_CONCURRENT event occurs.
The phone is a Motorola Atrix 2 running Android 2.3.5. I use the phone for development only so it has almost no additional apps than the stock bloatware from AT&T.
11-14 10:50:14.117: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4712K/9671K, external 2357K/2773K, paused 3ms+3ms
11-14 10:50:14.273: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4714K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:14.429: D/dalvikvm(724): GC_CONCURRENT freed 1431K, 52% free 4712K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:14.585: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4714K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:14.742: D/dalvikvm(724): GC_CONCURRENT freed 1428K, 52% free 4714K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:14.898: D/dalvikvm(724): GC_CONCURRENT freed 1430K, 52% free 4713K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:15.054: D/dalvikvm(724): GC_CONCURRENT freed 1427K, 52% free 4714K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:15.210: D/dalvikvm(724): GC_CONCURRENT freed 1432K, 52% free 4711K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:15.367: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4712K/9671K, external 2357K/2773K, paused 3ms+2ms
11-14 10:50:15.523: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4714K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:15.679: D/dalvikvm(724): GC_CONCURRENT freed 1432K, 52% free 4711K/9671K, external 2357K/2773K, paused 3ms+3ms
11-14 10:50:15.835: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4712K/9671K, external 2357K/2773K, paused 3ms+2ms
11-14 10:50:15.992: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4714K/9671K, external 2357K/2773K, paused 2ms+2ms
11-14 10:50:16.148: D/dalvikvm(724): GC_CONCURRENT freed 1429K, 52% free 4713K/9671K, external 2357K/2773K, paused 3ms+3ms
11-14 10:50:16.304: D/dalvikvm(724): GC_CONCURRENT freed 1429K, 52% free 4712K/9671K, external 2357K/2773K, paused 3ms+3ms
11-14 10:50:16.460: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4714K/9671K, external 2357K/2773K, paused 2ms+3ms
11-14 10:50:16.617: D/dalvikvm(724): GC_CONCURRENT freed 1430K, 52% free 4713K/9671K, external 2357K/2773K, paused 3ms+3ms
11-14 10:50:16.773: D/dalvikvm(724): GC_CONCURRENT freed 1429K, 52% free 4712K/9671K, external 2357K/2773K, paused 3ms+3ms
11-14 10:50:16.929: D/dalvikvm(724): GC_CONCURRENT freed 1426K, 52% free 4714K/9671K, external 2357K/2773K, paused 3ms+3ms
The process ID is shown in the message (in the above, it's pid 724). You can use adb shell ps to get the Linux process dump; find the entry for pid 724 to see which app it is.
Alternatively, if you're on a developer device, within Eclipse/ADT/DDMS you can open the "Devices" view and see all processes. Select the app with the matching pid (second column), then open the "Threads" view. This shows all the threads in the app. Look for a thread with high values in the "utime" and "stime" columns. If you double-click on it a few times, you will see snapshots of the stack trace that might suggest what's causing all the GCs.
Related
When I click on the share button of my App, a message shows Unfortunately has stopped. But, this doesn't cause the app to crash. I am able to share my file. The logcat doesn't show any errors. The following is what my logcat displays .
03-28 15:10:23.585 18455-18455/com.example.akn.play_music D/dalvikvm﹕ GC_FOR_ALLOC freed 208K, 2% free 17001K/17240K, paused 28ms, total 28ms
03-28 15:10:25.165 18455-18455/com.example.akn.play_music D/dalvikvm﹕ GC_FOR_ALLOC freed 142K, 2% free 17003K/17312K, paused 11ms, total 12ms
03-28 15:10:25.175 18455-18464/com.example.akn.play_music D/dalvikvm﹕ GC_FOR_ALLOC freed 3K, 2% free 17576K/17892K, paused 11ms, total 11ms
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.
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
I see a lot of this:
06-19 17:29:11.911: DEBUG/dalvikvm(10028): GC_FOR_MALLOC freed 729K, 54% free 3490K/7431K, external 0K/512K, paused 39ms
06-19 17:29:11.941: DEBUG/dalvikvm(10028): GC_FOR_MALLOC freed <1K, 49% free 3855K/7431K, external 0K/512K, paused 29ms
repeatedly in the log. Is there a way to not show the Dalvik debug messages?
Simply set a logcat filter. You can do this graphically in Eclipse as well.
Why does Android system always call garbage collection every time I make a request to web server to get images? Although I did every actions are asynchronous. Calling GC too many times make my app delays when scrolling or fling.
Update: I guess Android system always call GC when you do something request to web server. Here is the log when using the Android default browser. Each time you click on a link GC will be called automatically.
03-08 16:36:19.530: D/dalvikvm(341): GC_FOR_ALLOC freed 2124K, 31% free 10780K/15623K, paused 49ms
03-08 16:36:19.590: D/dalvikvm(341): GC_FOR_ALLOC freed 0K, 20% free 12635K/15623K, paused 49ms
03-08 16:36:19.700: D/dalvikvm(341): GC_CONCURRENT freed 1K, 20% free 12635K/15623K, paused 3ms+4ms
03-08 16:36:22.610: D/dalvikvm(20845): GC_CONCURRENT freed 735K, 10% free 9018K/9991K, paused 2ms+6ms
03-08 16:36:25.620: D/dalvikvm(20845): GC_CONCURRENT freed 1046K, 12% free 8954K/10119K, paused 4ms+3ms
03-08 16:36:27.880: D/dalvikvm(2781): GC_EXPLICIT freed 263K, 7% free 6373K/6791K, paused 2ms+2ms
03-08 16:36:28.950: D/dalvikvm(20845): GC_CONCURRENT freed 884K, 12% free 8946K/10119K, paused 3ms+3ms
03-08 16:36:29.760: D/dalvikvm(20845): GC_CONCURRENT freed 861K, 12% free 8949K/10119K, paused 3ms+3ms
03-08 16:36:31.390: D/dalvikvm(285): GC_EXPLICIT freed 1275K, 38% free 20843K/33223K, paused 17ms+8ms
03-08 16:36:31.510: D/dalvikvm(20845): GC_CONCURRENT freed 810K, 12% free 8946K/10119K, paused 3ms+5ms
03-08 16:36:38.100: D/dalvikvm(20845): GC_CONCURRENT freed 730K, 11% free 9027K/10119K, paused 3ms+6ms
03-08 16:36:40.920: D/dalvikvm(20845): GC_CONCURRENT freed 864K, 12% free 8989K/10119K, paused 2ms+5ms
03-08 16:36:45.780: D/dalvikvm(20845): GC_FOR_ALLOC freed 620K, 12% free 8909K/10119K, paused 41ms
03-08 16:36:48.250: D/dalvikvm(20845): GC_FOR_ALLOC freed 499K, 12% free 9002K/10119K, paused 45ms
03-08 16:36:48.570: D/dalvikvm(20845): GC_FOR_ALLOC freed 225K, 13% free 8899K/10119K, paused 28ms
03-08 16:36:50.670: D/dalvikvm(20845): GC_FOR_ALLOC freed 388K, 12% free 8915K/10119K, paused 34ms
03-08 16:36:52.550: D/dalvikvm(20845): GC_FOR_ALLOC freed 511K, 11% free 9008K/10119K, paused 44ms
03-08 16:36:53.780: D/dalvikvm(20845): GC_FOR_ALLOC freed 273K, 12% free 8909K/10119K, paused 42ms
03-08 16:37:05.070: D/dalvikvm(569): GC_EXPLICIT freed 376K, 12% free 6207K/6983K, paused 2ms+2ms
03-08 16:37:25.550: D/dalvikvm(2549): GC_CONCURRENT freed 337K, 9% free 7198K/7879K, paused 2ms+3ms
03-08 16:37:31.330: D/dalvikvm(2549): GC_EXPLICIT freed 54K, 10% free 7143K/7879K, paused 7ms+2ms
03-08 16:38:45.630: D/dalvikvm(2549): GC_EXPLICIT freed 268K, 10% free 7161K/7879K, paused 7ms+2ms
Android GC is automatic, opaque, non-deterministic. Which means you have nothing can do on it.
Traditionally, this type of GC works like this.
Wait until enough garbages are generated.
If GC engine thinks it's time, it stops your app.
Clear the garbages
Resume your app.
Of course, this sucks for end-use UI and graphics.
So Google added incremental collection. Essentially, this is just doing above procedure more frequently with less garbages. So pause time itself would be short but collection itself happens a lot more frequently.
As a conclusion, garbage collection happens randomly, but very frequently. So it would look happening always for any of operations.
Practically, there's no guaranteed way to avoid GC lag on typical GC systems.