Does calling free or delete ever release memory back to the "system"

Question

Hi

Here's my question : Does calling free or delete ever release memory back to the "system". By system I mean, does it ever reduce the data segment of the process ?

Lets consider the memory allocator on Linux, i.e ptmalloc.

From what I know(please correct me if I am wrong), ptmalloc maintains a free list of memory blocks and when a request for memory allocation comes, it tries to allocate a memory block from this free list(I know, the allocator is much more complex than that but I am just putting it in simple words) If however, it fails, it gets the memory from the system using say sbrk or brk system calls. When a memory is free'd, that block is placed in the free list.

Now consider this scenario, on peak load, a lot of objects have been allocated on heap. Now when the load decreases, the objects are free'd. So my question is: Once the object is free'd will the allocator do some calculations to find whether it should just keep this object in the free list or depending upon the current size of the free list it may decide to give that memory back to the system i.e decrease the data segment of the process using sbrk or brk.

Documentation of glibc tells me that if the allocation request is much larger than page size, it will be allocated using mmap and will be directly released back to the system once free'd. Cool. But lets say I never ask for allocation of size greater than say 50 bytes and I ask a lot of such 50 byte objects on peak load on the system. Then what ?

From what I know(correct me please), a memory allocated with malloc will never be released back to the system ever until the process ends i.e the allocator will simply keep it in the free list if I free it. But the question that is troubling me is then, if I use a tool to see the memory usage of my process(I am using pmap on Linux, what do you guys use ?), it should always show the memory used at peak load(as the memory is never given back to the system, except when allocated using mmap) ? That is memory used by the process should never ever decrease(except the stack memory) ? Is it ?

I know I am missing something, so please shed some light on all this.

Experts, please clear my concepts regarding this. I will be grateful. I hope I was able to explain my question.

Thank you all for your patience.

Regards lali

Answer 1

It is entirely implementation dependent. On Windows VC++ programs can return memory back to the system if the corresponding memory pages contain only free'd blocks.

Answer 2

I think that you have all the information you need to answer your own question. pmap shows the memory that is currenly being used by the process. So, if you call pmap before the process achieves peak memory, then no it will not show peak memory. if you call pmap just before the process exits, then it will show peak memory for a process that does not use mmap. If the process uses mmap, then if you call pmap at the point where maximum memory is being used, it will show peak memory usage, but this point may not be at the end of the process (it could occur anywhere).

This applies only to your current system (i.e. based on the documentation you have provided for free and mmap and malloc) but as the previous poster has stated, behavior of these is implmentation dependent.

Answer 3

This varies a bit from implementation to implementation.

Think of your memory as a massive long block, when you allocate to it you take a bit out of your memory (labeled '1' below):

111

If I allocate more more memory with malloc it gets some from the system:

1112222

If I now free '1':

___2222

It won't be returned to the system, because two is in front of it (and memory is given as a continous block). However if the end of the memory is freed, then that memory is returned to the system. If I freed '2' instead of '1'. I would get:

111

the bit where '2' was would be returned to the system. The main benefit of freeing memory is that that bit can then be reallocated, as opposed to getting more memory from the system. e.g:

33_2222

Answer 4

Here are some "advantages" to never releasing memory back to the system:

• Having already used a lot of memory makes it very likely you will do so again, and
  • when you release memory the OS has to do quite a bit of paperwork
  • when you need it again, your memory allocator has to re-initialise all its data structures in the region it just received
• Freed memory that isn't needed gets paged out to disk where it doesn't actually make that much difference
• Often, even if you free 90% of your memory, fragmentation means that very few pages can actually be released, so the effort required to look for empty pages isn't terribly well spent

Answer 5

I believe that the memory allocator in glibc can return memory back to the system, but whether it will or not depends on your memory allocation patterns.

Let's say you do something like this:

void *pointers[10000];
for(i = 0; i < 10000; i++)
    pointers[i] = malloc(1024);
for(i = 0; i < 9999; i++)
    free(pointers[i]);

The only part of the heap that can be safely returned to the system is the "wilderness chunk", which is at the end of the heap. This can be returned to the system using another sbrk system call, and the glibc memory allocator will do that when the size of this last chunk exceeds some threshold.

The above program would make 10000 small allocations, but only free the first 9999 of them. The last one should (assuming nothing else has called malloc, which is unlikely) be sitting right at the end of the heap. This would prevent the allocator from returning any memory to the system at all.

If you were to free the remaining allocation, glibc's malloc implementation should be able to return most of the pages allocated back to the system.

If you're allocating and freeing small chunks of memory, a few of which are long-lived, you could end up in a situation where you have a large chunk of memory allocated from the system, but you're only using a tiny fraction of it.

Answer 6

There isn't much overhead for malloc, so you are unlikely to achieve any run-time savings. There is, however, a good reason to implement an allocator on top of malloc, and that is to be able to trace memory leaks. For example, you can free all memory allocated by the program when it exits, and then check to see if your memory allocator calls balance (i.e. same number of calls to allocate/deallocate).

For your specific implementation, there is no reason to free() since the malloc won't release to system memory and so it will only release memory back to your own allocator.

Another reason for using a custom allocator is that you may be allocating many objects of the same size (i.e you have some data structure that you are allocating a lot). You may want to maintain a separate free list for this type of object, and free/allocate only from this special list. The advantage of this is that it will avoid memory fragmentation.

Answer 7

Many memory managers can perform TRIM operations where they return entirely unused blocks of memory to the OS. However, as several posts here have mentioned, it's entirely implementation dependent.

But lets say I never ask for allocation of size greater than say 50 bytes and I ask a lot of such 50 byte objects on peak load on the system. Then what ?

This depends on your allocation pattern. Do you free ALL of the small allocations? If so and if the memory manager has handling for a small block allocations, then this may be possible. However, if you allocate many small items and then only free all but a few scattered items, you may fragment memory and make it impossible to TRIM blocks since each block will have only a few straggling allocations. In this case, you may want to use a different allocation scheme for the temporary allocations and the persistant ones so you can return the temporary allocations back to the OS.