The problem with free () on structs in C. It does not reduce memory usage

Question

I have a problem with free () in the structure in my C program. When I look at / proc // statm before and after free, it does not seem to decrease. Am I using free () incorrectly in this case, or am I reading / proc // statm incorrectly?

Here is a test case that gives the problem:

struct mystruct { unsigned int arr[10000]; }; void mem() { char buf[30]; snprintf(buf, 30, "/proc/%u/statm", (unsigned)getpid()); FILE* pf = fopen(buf, "r"); if (pf) { unsigned size; // total program size unsigned resident;// resident set size unsigned share;// shared pages unsigned text;// text (code) unsigned lib;// library unsigned data;// data/stack unsigned dt;// dirty pages (unused in Linux 2.6) fscanf(pf, "%u %u %u %u %u %u", &size, &resident, &share, &text, &lib, &data); printf("Memory usage: Data = %d\n", data*sysconf(_SC_PAGESIZE)); } fclose(pf); } int main(int argc, char **argv) { mem(); struct mystruct *foo = (struct mystruct *)malloc(sizeof(struct mystruct)); mem(); free(foo); mem(); } 

Output:

 Memory usage: Data = 278528 Memory usage: Data = 282624 Memory usage: Data = 282624 

When I expect it to be:

 Memory usage: Data = 278528 Memory usage: Data = 282624 Memory usage: Data = 278528 

I did a similar test with malloc'ing (char *), then released it and it works fine. Is there anything special about structures?

Answer 1

Your answer is right here in the stack overflow , but the short version is that for very good reasons the memory allocator does not return memory to the main OS but saves it (internally in your program data space) as a free list.

Some of the reasons the library stores memory are:

• Interaction with the kernel is much slower than just executing library code
  
• The allowance will be small. Most programs have a steady or growing amount of memory, so the time taken to analyze the heap looking for recurrent memory will be completely lost.
• Internal fragmentation makes blocks aligned on pages (the only thing that can be returned to the kernel) is unlikely to exist, another reason not to slow down the program and look for something that will not be there.
• Returning a page embedded in a free block will fragment the bottom and top of the block on both sides of the page.
• A few programs that actually return large amounts of memory are likely to bypass malloc () and simply allocate and free pages anyway using mmap (2).

Answer 2

Whenever free actually frees memory is implementation dependent. Thus, perhaps free does not return memory immediately when it is a large chunk in memory. I don't think this has anything to do with struct s.

Answer 3

Basically, for performance reasons, the allocated heap memory will not be returned to the OS after release. It will be marked as free, although it may be that the kernel will return it later, or your program will select it and use it again.

I do not know what you used to allocate / release (char *) . The difference you saw may be that your (char *) was allocated on the stack, and the release / process is different from the heap for free (managing stack memory is much simpler).

Answer 4

It is true for the OS to free up your data and therefore reduce the memory consumption of your program. You will only say that you will no longer use this memory.