How heap memory allocation works

Question

I'm working on an app and I have memory issues. I started to study this thing and I have met Eclipse's debugging system.

I use DDMS's Heap tester to see how much memory my app allocated. I saw it's about 90%.

Now I made a simple new project, a blank empty activity without any functions or variables. Just a splendid new project.

I ran this heap tester and I saw the results:

Heap size: 10,629 MB  
Allocated: 9,189 MB
Free: 1,440 MB
Used: 86.45 %
Objects: 44,565

Well, is it normal? I have a very simple blank activity, and nothing else, and this app is used 86% of memory?

Allocated 9 MB of 10? Really? Is that normal? How this works?

Please instruct me about this, because I would like to know how these memory allocations work.

Answer 1

Examining Heap Usage is somewhat tricky but is equally easy. Let's find out how.

So consider a small application. You have Android debugging tools to determine the heap usage and to examine them.

You can check this- memory-analysis-for-android, which have more details of how to analize the application effectively in android.

Let's have a short description here too:

There are two ways to start DDMS-

1) Using Eclipse: click Window > Open Perspective > Other... > DDMS

2) or from the command line: run ddms (or ./ddms on Mac/Linux) in the tools/ directory

Then select your application process from Devices and click "Update Heap".

Now switch to the Heap tab in DDMS. To see the first update, click the Cause GC button.

You will see something like this:

We can see that our set (the Allocated column) is a little over 20MB. If you do some little flip flop, that number can go up. In small applications, the amount of memory we leak is bounded. In some ways, this can be the worst kind of leak to have, because we never get an OutOfMemoryError indicating that we are leaking.

You can use Heap Dump to identify the problem. Click the Dump HPROF file button in the DDMS toolbar and save the file wherever you want. Then run hprof-conv on it.

Using MAT which is a powerful Memory Analyzer tool-

You can install MAT from SITE which is a stand-alone Memory Analyzer tool and analyze the Heap dumps using it.

NOTE: If you're running ADT (which includes a plug-in version of DDMS) and have MAT installed in Eclipse as well, clicking the "dump HPROF" button will automatically do the conversion (using hprof-conv) and open the converted hprof file into Eclipse (which will be opened by MAT).

Start the MAT and load the converted HPROF file. Navigate to the Histogram view which shows a list of classes sortable by the number of instances, the shallow heap (total amount of memory used by all instances), or the retained heap (total amount of memory kept alive by all instances, including other objects that they have references to).

If we sort by shallow heap, we can see that instances of byte[] are at the top.

Next, Right-click on the byte[] class and select List Objects > with incoming references. This produces a list of all byte arrays in the heap, which we can sort based on Shallow Heap usage.

Pick one of the big objects, and drill down on it. This will show you the path from the root set to the object - the chain of references that keeps this object alive. Lo and behold, there's our bitmap cache!

MAT can't tell us for sure that this is a leak, because it doesn't know whether these objects are needed or not -- only the programmer can do that. However, looking at the stats it is predictable to know that the cache is using a large amount of memory relative to the rest of the application, so we might consider limiting the size of the cache.

Go this way all along for all, and you will see a tremendous amount of performance optimization.

Answer 2

Dalvik will initially allocate a certain heap size to your app. In your case, this is around 10 MB. As your app needs more memory, Dalvik will increase the heap size upto the maximum configured size (which is different for different devices). If your app still needs more memory after the maximum is reached, then it will cause a OutOfMemoryException.

To learn more about analyzing memory allocations in Android, check out this excellent article from the Android developers blog:

http://android-developers.blogspot.in/2011/03/memory-analysis-for-android.html

Answer 3

What you see here is allocated memory and not maximum memory which can be allocated, maximum memory which can be allocated depends upon android version and device to device.

In this case, your apps does not have any high memory requirement, all the files,system and object being used to run the app is very small hence initially android has allocated your app a common initial space,now this space goes on increasing as demand from app increases until its met, or it exceeds maximum heap size defines per app by android, in this scenario your app will crash stating running out of memory as reason.

To read more about memory allocation in android go through below developer link

http://developer.android.com/training/articles/memory.html