5

I am developing an application on Android. It is a long running application that continuously processes sensor data. While running the application I see a lot of GC messages in the logcat; about one every second.

This is most probably because of objects being created and immediately de-referenced in a loop.

How do I find which objects are being created and released immediately?

All the java heap analysis tools that I have tried(*) are bothered with the counts and sizes of objects on the heap. While they are useful, I am more interested in finding out the site where temporary short-lived objects get created the most.

(*) I tried jcat and Eclipse MAT. I couldn't get hat to work on the Android heap-dumps; it complained of an unsupported dump file version.

HRJ
  • 17,079
  • 11
  • 56
  • 80

2 Answers2

4

How do I find which objects are being created and released immediately?

Step #1: Temporarily modify your code (or create a scrap project with the relevant portions of your code), where you can click a button or something to run exactly once through the sensor processing logic.

Step #2: Get into DDMS (standalone or the Eclipse perspective).

Step #3: Choose your emulator, then click on the Allocation Tracker tab

Step #4: Get your application to the point where it is waiting for the button click from step #1, then click on Start Tracking in the DDMS Allocation Tracker tab.

Step #4: Click the button, and when the sensor processing pass is complete, click Get Allocations on the DDMS Allocation Tracker tab.

This will tell you what was allocated during that portion of your code. It does not tell you what is "released", because that's indeterminate until a GC cycle runs.

EDIT

I am not certain, but startAllocCounting() on the android.os.Debug class may have the same effect as clicking the Start Tracking button. If so, you could simply instrument your code to track allocations over one pass of your loop, rather than mess around with the code changes I outlined above.

And, FWIW, here is a short technical article on DDMS and allocation tracking.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 1
    double posted :\ why not running allocation tracker without changing the code? (at least the for the first time) – Pedro Loureiro Dec 27 '10 at 12:40
  • 1
    @Pedro Loureiro: First, you wind up with a lot of allocations outside of the loop in question, and the allocations list can get really long. Second, the loop itself may make the list impossibly long to manage. Isolating one pass over the relevant segment of code will make it easiest to understand the data. However, your comment did remind me of something, that I'll be adding to my answer momentarily... – CommonsWare Dec 27 '10 at 12:47
  • Thanks for the pointer to Allocation Tracker. Had completely missed it. Btw, the doc says it is not available in the Eclipse integration (ADT) – HRJ Dec 27 '10 at 12:49
  • 1
    @HRJ: that's possible -- I don't use Eclipse. However, the tools have undergone a fairly significant round of revisions recently, so you might double-check to make sure that's not a documentation error. Note, though, that if it is correct, you will need to have Eclipse shut down while you are using the standalone DDMS, as you cannot have two DDMS's running at once, AFAIK. – CommonsWare Dec 27 '10 at 12:50
1

I think you need to give allocation tracker a try :)

(in your /tools dir)

http://developer.android.com/resources/articles/track-mem.html

Pedro Loureiro
  • 11,436
  • 2
  • 31
  • 37