pushpakulkar@gmail.com writes:

> Hi all,
>
> If I have a piece of code something like this
>
> int main()
> {
>
> char *s1;
>
> s1= (char *) malloc(sizeof(char) * 200)
> while(somecondition)
> {
> ................... //do something
>
> }
>
> free(s1);
>
> while(true)
> {
> ;
> } //Infinite loop
> }
>
>
>
> This is just a sample code, please ignore the syntax errors.
>
> In the above piece of code during execution malloc results in
> allocating space physically in the RAM. Now after the first while loop
> execution is complete free(s1) is called. At this point of time is
> memory returned back to the OS or not always. I guess memory is just
> marked as freed for future use by the same process.
>
> I have read that in some implementations of OS like some unix flavors
> even after free() is executed memory is not released back to the
> system. In the above piece of code is it the case that the memory is
> never freed up at all in such implementations and remains tied up till
> the process dies.


That's commonly true.

> Assuming there is a need for memory by some other process and no other
> free memory is available, is it the case malloc for the other process
> would fail under such circumstances.


Yes, it could.

> Does the OS do some kind of
> tracking and free up this memory. Is there any way to force freeing
> up the memory to the system back.


This is system-specific and becoming off-topic for comp.lang.c. Since
you mention Unix systems, I'll answer your question as it relates to
them. I've cross-posted and set followups to comp.unix.programmer.

First of all, the operating system only deals with memory in units of
pages, whose size varies between systems but is usually on the order of
a few Kbyte. (4K and 8K are common.) So anything smaller than that,
like the 200 byte allocation in your example, can't be returned to the
OS at all, unless there's nothing else in the page where it resides. Of
course, if it's only 200 bytes you probably don't care anyway, so let's
assume we're talking about a much larger amount of memory.

A partial answer to your question is that a page that isn't used in a
while will be swapped out to disk, so that it no longer occupies
physical memory. But swap space is also finite, and when you run out
you will still see other programs fail to allocate memory.

Now, there are two ways to allocate and deallocate memory from the OS
(in multiples of a page). One is sbrk(), which resizes your program's
"main" data segment. Although it can sometimes be used to shrink the
segment, this would only allow you to free whatever happens to be at the
very end, not something in the middle.

The more useful mechanism for this purpose is mmap(), which was
originally designed for mapping files into memory, but also has an
"anonymous" mode that just allocates a chunk of memory, and maps it
somewhere far away from the main data segment. Such a chunk can later
be freed with munmap(). So if you need to allocate a large block and
ensure that it's given back to the OS later, mmap()/munmap() is your
best bet.

On some systems (Linux and FreeBSD for example), malloc()/free()
themselves will use this mechanism when you allocate a large enough
chunk of memory (megabytes). So on such systems this is taken care of
for you.

Hope this helps. Post on comp.unix.programmer if you'd like more details.