Doubts about free()

[pushpakulkar]

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.

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. 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.

Thanks and Regards,
Pushpa

 

[James Kuyper]

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. ...

Where the memory is located is a implementation detail. It might
actually be stored on a hard disk, or somewhere else entirely; on
machines with virtual memory, any sufficiently large allocation will
probably reside on a hard disk for at least part of its lifetime, if you
hold onto it for sufficiently long.

... 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.

The answer is different on different systems. You'll have to identify a
specific system to get a specific answer.

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. 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.

The C standard library provides no such mechanism. I'm not familiar with
any way of doing so on any of the Unix-like systems that most of my
programs run on.

 

[Pawel Dziepak]

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. 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.

I don't think that managing memory in that way is a program's job. You
just have to allocate memory (malloc) and release it (free). The
implementation specific details shouldn't bother you, unless you are
writing specialized program that requires good performance and uses
many resources.

In such kind of implementations which does not release pages of memory
allocated by the program, pages full of "empty and reserced" blocks
probably will be swapped, and there won't be any problems with
allocating memory for other processes.

If you want to get on the lower level of managing memory, you will
need to write your own implementation of malloc/free functions.
However, then you need to use platform dependent functions such as
sbrk in POSIX.

Pawel Dziepak

 

[vippstar]

I don't think that <snip>

Please don't remove attribution lines.
<http://www.netmeister.org/news/learn2quote1.html>

 

[Nate Eldredge]

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.

 

[Ian Collins]

Please don't remove attribution lines.
<http://www.netmeister.org/news/learn2quote1.html>

Why pick on this bloke rather than that arrogant prat Burditt?

 

[Keith Thompson]

Why pick on this bloke rather than that arrogant prat Burditt?

Not speaking for vippstar, but experience has shown that picking on
that arrogant prat Burditt is ineffective.

 

[David Schwartz]

In the above piece of code during execution malloc results in
allocating space physically in the RAM.

Yes, if and only if the system library and operating system think
that's the right thing to do. All that is guaranteed is that address
space local to this process be reserved.

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.

Your use of the term "memory" is ambiguous. It could mean physical
memory, virtual memory, or some confused combination of the two. Since
all that had to be reserved was address space local to the process,
that's all that has to be recovered, and it is on every implementation
I know of.

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.

If you're talking about physical memory, which is probably the only
thing that's scarce, modern operating systems never give that to a
process without retaining the ability to recover it if needed. The
exception would be specific calls to lock memory. Physical memory
mapped to meet the demands of 'malloc' is never locked into the
process. It can always be recovered if physical memory can better be
used elsewhere.

 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.

If you mean system wide virtual memory, probably. If you mean physical
memory, definitely not.

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. 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.

It's almost impossible to answer that, because it's not clear what you
mean by "memory". In normal circumstances, only physical memory would
be scarce. Physical memory can easily be reclaimed by the OS.

DS

 

[Bill Cunningham]

In a UNIX system this operation is often called 'kill'.

Make sure to get the PID or process id you want to kill. ps might give
you that. It's ps ax on my linux.

Bill

kill pid

 

[CBFalconer]

Why pick on this bloke rather than that arrogant prat Burditt?

Among other things, vippstar made a reply to Dziepaks message, and
there was no material from any user named "arrogant prat Burditt"
involved. I suspect that vippstars motive is to correct Dziepak
early in his Usenet involvement, so that he never develops odious
habits.