Memory Handling is a problem with the compiler or OS ?

[Vishal Augustine]

Hi,

Pardon me if this question is a repetition.

When I use new/malloc in my code, memory gets allocated in the heap of the process. When I use free/delete it is released; but not back to the system. It retains the memory within the process so that it can make use of it in the next malloc/new call.

My doubt is, is this something to do with the compiler or OS ? There are system calls (mmap/munmap) that will explicitly release the memory back to the system from the process. Those calls are not being used/incorporated by the compiler, when it creates the binary. Am I right ? In that case, if I want to change the way in which delete/free behaves I need to change my compiler ... right ?

How expensive is to get memory from the system rather than from the process space ? Why does compilers do it this way ? How good will it be if I overload new/delete to behave in the other way ?

Please do reply

Thanks and Regards
Vishal

[harry d brown jr]

Vishal,

The answer is Neither.

http://docs.hp.com/cgi-bin/otsearch/getfile?id=/hpux/onlinedocs/os/11i/mem_mgt.html&searchterms=memory%20management&queryid=20020320-082233

live free or die
harry

[A. Clay Stephenson]

Hi:

This is normal behavior. When you use malloc(), calloc(), or realloc() to allocate memory and then use free() to release the memory, it is not returned to the OS. It is returned to the process's heap for further use by more malloc()'s. You can use the sbrk() system call with a negative value to return memory to the OS but this is not for the faint of heart. If you choose to use sbrk() you MUST NOT USE the higher-level malloc() related functions or absolute chaos will result. If you you sbrk(), you assume full responsibility for process memory management.

[John Payne_2]

Clay is right, this is an OS feature. The reason why the memory is not returned to the system is the idea that if your process is going to need memory later, there is less overhead involved. The reason is that the active memory for your process sits on the processor cache. If the memory remains on the cache, the processor does not have to go out to the bus to make a memory request. If the memory was returned to the system, the processor would be guarenteed a trip out to the bus to request memory.

John

[Steven Gillard_2]

Its not the compiler or the OS, its simply the way the high level memory management routines of libc such as malloc and free work. As Clay correctly points out you can avoid use of these such routines and call the lower level sbrk() system call directly, but doing so is messy business.

Something else you may want to investigate is a garbage collector such as that available from HP labs:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

I'm not sure this will do exactly what you want (ie release memory back to the OS through calls to sbrk with negative arguments) because I haven't had a chance to try it out myself, but it does contain replacements for the malloc/free routines and the source code is all there. It also works with C++'s new and delete operators.

Regards,
Steve