How to Find Size of Heap Present in Linux

How to check heap size for a process on Linux

The heap usually is as large as the addressable virtual memory on your architecture.

You should check your systems current limits with the ulimit -a command and seek this line max memory size (kbytes, -m) 3008828, this line on my OpenSuse 11.4 x86_64 with ~3.5 GiB of ram says I have roughly 3GB of ram per process.

Then you can truly test your system using this simple program to check max usable memory per process:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc,char* argv[]){
        size_t oneHundredMiB=100*1048576;
        size_t maxMemMiB=0;
        void *memPointer = NULL;
        do{
                if(memPointer != NULL){
                        printf("Max Tested Memory = %zi\n",maxMemMiB);
                        memset(memPointer,0,maxMemMiB);
                        free(memPointer);
                }
                maxMemMiB+=oneHundredMiB;
                memPointer=malloc(maxMemMiB);
        }while(memPointer != NULL);
        printf("Max Usable Memory aprox = %zi\n",maxMemMiB-oneHundredMiB);
        return 0;
}

This programs gets memory on 100MiB increments, presents the currently allocated memory, allocates 0's on it,then frees the memory. When the system can't give more memory, returns NULL and it displays the final max usable amount of ram.

The Caveat is that your system will start to heavily swap memory in the final stages. Depending on your system configuration, the kernel might decide to kill some processes. I use a 100 MiB increments so there is some breathing space for some apps and the system. You should close anything that you don't want crashing.

That being said. In my system where I'm writing this nothing crashed. And the program above reports barely the same as ulimit -a. The difference is that it actually tested the memory and by means of memset() confirmed the memory was given and used.

For comparison on a Ubuntu 10.04x86 VM with 256 MiB of ram and 400MiB of swap the ulimit report was memory size (kbytes, -m) unlimited and my little program reported 524.288.000 bytes, which is roughly the combined ram and swap, discounting ram used by others software and the kernel.

Edit: As Adam Zalcman wrote, ulimit -m is no longer honored on newer 2.6 and up linux kernels, so i stand corrected. But ulimit -v is honored. For practical results you should replace -m with -v, and look for virtual memory (kbytes, -v) 4515440. It seems mere chance that my suse box had the -m value coinciding with what my little utility reported. You should remember that this is virtual memory assigned by the kernel, if physical ram is insufficient it will take swap space to make up for it.

If you want to know how much physical ram is available without disturbing any process or the system, you can use

long total_available_ram =sysconf(_SC_AVPHYS_PAGES) * sysconf(_SC_PAGESIZE) ;

this will exclude cache and buffer memory, so this number can be far smaller than the actual available memory. OS caches can be quiet large and their eviction can give the needed extra memory, but that is handled by the kernel.

How to find size of heap present in Linux?

I don't know about specifics of the ARM Linux; however, assuming that you are talking about userspace application and not kernel space, there is inherently no 'heap size'. The 'classical unix way' of userspace memory management is an 'expanding heap' - the application has a heap of finite size and when it needs to expand it, it calls the brk() function.
I guess you have no swap and disabled overcommit on this platform - looki into /proc/meminfo (or output of 'top') to see the available memory.

Get the size of heap and stack per process in Linux

On Linux, you can read /proc/[PID]/maps and find [heap] and [stack] entries.

But for the GLIBC heap implementations usually used on Linux, the "heap" consists of both memory obtained via sbrk() that shows up in the /proc/[PID]/maps file as [heap] and memory obtained via mmap() - see this quesiton. So the "size" of the heap is going to be very hard to determine with certainty.

And the region labelled [stack] in the maps file is the stack for the main thread only. Multithreaded processes will have multiple stacks, one for each thread. And they will show up in the maps file as anonymous memory - maybe. The application can control the memory used for a thread's stack via the use of pthread_attr_setstack() and set it to any memory the application might use.

how to check heap size allocated for jvm by linux

You can easily check the heap size memory allocation using JConsole, if you have a path to your jre/jdk set up correctly on the system you should be able to start it with command jconsole from anywhere.

For managing your heap memory allocation you can have a look here: http://javahowto.blogspot.com/2006/06/6-common-errors-in-setting-java-heap.html

Get size of memory available on the heap

The distinction between stack and heap are somewhat vague in Linux. Stack is just memory, the top of which, is handed to a clone() call which creates the new task. This is true both for new processes and new threads. The allocator operators are wrappers around system calls brk/sbrk. Your best bet is to override the global operator new/operator new[] and operator delete/operator delete[] to do some sort of counting of the calls in such a way that you can examine it at run time.

A quick read through new expression can give you a good idea of order in which things happen when an object is created/destroyed (forgive me if you already know this) and operator new will tell the order in which allocators are looked up. I may be wrong about this, but in order to have all allocators go through the same point of requesting memory from the OS, even the class-specific operator new would have to eventually call global operator new.

Well, the class-specific ones could use the allocator to mmap memory to a file or shmget to map the object to some storage in shared memory, but in both of those cases it wouldn't be part of what is traditionally referred to as "the heap." The stack+heap both reside in what you see as "VIRT" memory when you run "top" in linux.

Short of that, the memory allocated by malloc and passed to the clone call (which, for instance, creates a new thread) to be the stack of a new thread will not be different from the memory used as heap.

Size of stack and heap memory

"Stack is created in the top-level-address and the heap at the
low-level-address" Please elobarate this

This is a myth. It may have a basis in historical truth. It might sometimes resonate with things you see in real life. But it is not literally true.

It's easy enough to explore, though:

#include <stdlib.h>
#include <stdio.h>

void check(int depth) {
    char c;
    char *ptr = malloc(1);
    printf("stack at %p, heap at %p\n", &c, ptr);
    if (depth <= 0) return;
    check(depth-1);
}

int main() {
    check(10);
    return 0;
}

On my machine I see:

stack at 0x22ac3b, heap at 0x20010240
stack at 0x22ac0b, heap at 0x200485b0
stack at 0x22abdb, heap at 0x200485c0
stack at 0x22abab, heap at 0x200485d0
stack at 0x22ab7b, heap at 0x200485e0
stack at 0x22ab4b, heap at 0x200485f0
stack at 0x22ab1b, heap at 0x20048600
stack at 0x22aaeb, heap at 0x20048610
stack at 0x22aabb, heap at 0x20048620
stack at 0x22aa8b, heap at 0x20048630
stack at 0x22aa5b, heap at 0x20048640

So, the stack is going downwards and the heap is going upwards (as you might expect based on the myth), but the stack has the smaller address, and they are not growing toward each other (myth busted).

Btw, my check function is tail-recursive, and on some implementations with some compiler options you might see the stack not moving at all. Which tells you something about why the standard doesn't mandate how all this works -- if it did it might inadvertently forbid useful optimizations.

---

Related Topics