K
karthikbalaguru
Hi,
Will 'free' return the memory Immediately to the OS ?
Thx in advans,
Karthik Balaguru
Will 'free' return the memory Immediately to the OS ?
Thx in advans,
Karthik Balaguru
M
Mark Bluemel
karthikbalaguru said:
I believe Harold Pinter, when directing plays he wrote, would answer
questions about the characters, their motivation and so on by saying
"the text doesn't tell us"...
That's the answer here...
N
Nick Keighley
usually no. In fact usually the memory is only returned to the OS
when the program terminates. But this is all implementation
dependent.
--
Nick Keighley
"but that's the worse thing that could possibly happen!
but it's worse than that!"
an engineer on hearing of a fault
K
karthikbalaguru
Thx for your replies.
I agree on your view.
Interesting design followed by various OS .
I was thinking over this and have some queries based on this.
Generally,
If it does not return the memory immediately, then ,
- Will it not drain the memory ?
- Will it not add more load to the OS in managing it by still being
in the memory(hidden) ?
- Will it not cause problems if i allocate some memory immediately
after calling free (as it is not freed immediately).
- Why do some memory management design return the memory immediately
to the OS and some at the later stage. Is there any specific
advantage in either of these designs ?
Thx in advans,
Karthik Balaguru
M
Mark McIntyre
karthikbalaguru said:
Yes to all these.
The answer is implementation-specific and offtopic in CLC.
comp.programming might possibly be a better place.
V
Vijay Kumar R. Zanvar
No and yes, but usually no. The standard library implementation may
not release the acquired memory to the OS. However, the program can
not use it anymore once freed.
Thanks,
Vijay Zanvar
http://faq.zanvar.in
R
Richard Tobin
karthikbalaguru said:
You seem to be misunderstanding. If the program doesn't return
the memory to the OS, it's almost certainly because it's keeping
it to use for future allocations in the same program.
It's very likely - though not of course guaranteed - that if you do
p = malloc(sizeof(*p));
free(p);
p = malloc(sizeof(*p));
then malloc() will return the same value both times.
Always returning memory to the OS is likely to be a very poor
strategy, because the overhead of calling the OS is usually very high
compared with having the program manage memory itself. The down side
is that the memory isn't available to other programs, but (a) in
practice, few programs allocate a large amount of memory, free it, and
don't allocate similar quantities later, and (b) on a system with
virtual memory it won't affect the availability of real memory, at
least for chunks of memory large compared with a page.
-- Richard
W
WANG Cong
On Mon, 25 Feb 2008 01:10:49 -0800，karthikbalaguru wrote：
It depends on how your free() is implemented.
Most libc's use a complex algorithm to do memory manangement,
in order to get the speed, maybe they won't give the memory
to OS immediately after free().
The C std just can guarantee that after your free(), that
memory block can be used for further malloc().
It depends on how your free() is implemented.
Most libc's use a complex algorithm to do memory manangement,
in order to get the speed, maybe they won't give the memory
to OS immediately after free().
The C std just can guarantee that after your free(), that
memory block can be used for further malloc().
S
santosh
karthikbalaguru said:
Please see a recent thread we had here and over in comp.std.c on whether
the memory given to free is kept around by the malloc system for future
allocations or whether it is (or can be) given back to the OS.
Virtual memory yes.
I think you are misunderstanding what freeing immediately actually
means. In fact the standard has nothing to say about when it is freed
and it could mean many things in many systems. I would guess that free
would remove the memory from the allocated list and add it to the free
list, at a minimum. This has to be done. Whether it also returns the
memory to the OS, i.e., shrinks the data segment of the process, is
totally implementation specific. Some systems do not even have an OS,
some systems have OSes that are too primitive for such flexibility and
so on.
Your best bet is to examine a few malloc/free implementations for
systems of your interest.
There is no consensus (nor a requirement in the standard) that memory
given to free need be returned to the OS *at* *all* .
The presence of virtual memory and paging will complicate these
decisions. As I said this is upto each malloc implementation to decide
and the only way to say for sure is to examine the sources for your
implementation and keep in mind that they apply only to that
implementation.
<snip>
W
WANG Cong
On Mon, 25 Feb 2008 01:49:05 -0800，karthikbalaguru wrote：
{snip}
Yes, of course. Your system has constant memory.
No, it can apply more memory first, then manage them by *itself* and
finally, when your program exits, gives all back to OS together.
No. malloc() or something like that is also controlled by libc,
it can alloc from its own memory instead of OS's.
The advantage of this is that it consumes less memory.
Maybe it works in a system has limited memory.
{snip}
Yes, of course. Your system has constant memory.
No, it can apply more memory first, then manage them by *itself* and
finally, when your program exits, gives all back to OS together.
No. malloc() or something like that is also controlled by libc,
it can alloc from its own memory instead of OS's.
The advantage of this is that it consumes less memory.
Maybe it works in a system has limited memory.
B
Bartc
karthikbalaguru said:
Think of an example:
p=malloc(16)
....
free(p)
Your malloc system now has 16 bytes at it's disposable. Should it go to the
OS and give it the 16 bytes?
What's the OS going to do with a measly 16 bytes? It would just waste
everyone's time. Malloc might as well hang on to those 16 bytes and make it
available for future allocations, or add it to other free memory to form a
bigger block.
Depending on what malloc does, there might be a minimum block size which it
uses to negotiate with the OS. And if there is, then maybe it can only
return the entire block, not part of it.
Of course if you allocate then free millions of 16-byte blocks, malloc
doesn't want to hang on to all that memory either. It should do something
sensible in this case. But simplify off-loading such problems to the OS just
defers the problem.
K
Kelsey Bjarnason
[snips]
Is it? I see nothing whatsoever in the definition of free which allows
for any implementation-defined behaviour; its behaviour, quite the
contrary, is absolutely and clearly defined, and *does not permit*
handing the memory back to the OS.
If you can find "implementation defined" in the definition of free, in a
manner which would allow the behaviour you describe, please quote it; I
cannot find it anywhere.
Is it? I see nothing whatsoever in the definition of free which allows
for any implementation-defined behaviour; its behaviour, quite the
contrary, is absolutely and clearly defined, and *does not permit*
handing the memory back to the OS.
If you can find "implementation defined" in the definition of free, in a
manner which would allow the behaviour you describe, please quote it; I
cannot find it anywhere.
K
Kelsey Bjarnason
The proper answer is that, according to the text of the standard, it
*cannot* return the memory to the OS; the definition of free simply does
not allow this.
That said, there are a lot of badly broken implementations out there
which do, in fact, return the memory to the OS, despite this making them
completely non-conforming. As to how _soon_ they do this, only the
implementer knows for certain.
C
CBFalconer
Vijay Kumar R. Zanvar said:
Normally the malloc system will get large blocks of memory from the
OS, chop it up, and pass it out as needed. Getting it from the OS
is a relatively expensive operation. When something is freed, it
is normally only a small portion of what the OS supplied, so it
just can't be returned.
The malloc system could keep trying to detect that a complete OS
supplied block has been freed, and return that. However that would
again be an expensive operation, so it probably won't be done.
R
Richard Tobin
[/QUOTE]
Those who didn't follow the recent thread on the subject should note
that this is merely a theory recently advanced by Kelsey; it does not
reflect any consensus on the subject; it is contrary to previous
interpretation of the standard; and at most implies the need for a
correction to the standard, rather than having any implication for
users or implementors of C.
-- Richard
S
santosh
Kelsey said:
I said implementation specific, not implementation defined, meaning
possibly non-conforming behaviour by implementations. From the POV of
the Standard, I suppose one can say that it is undefined by omission
whether free returns the memory to the OS, if any, or not. Thus they
(the implementations) can do whatever they like, as long as they
fullfill the wording of malloc and free in the Standard.
The following program demonstrates how at least one implementation (gcc
4.1.0 under Linux 2.6.15) *does* return the allocated memory back to
the OS after free has been called on it.
code:
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <limits.h>
#define DEFAULT_SIZE 134217728UL
int main(int argc, char **argv) {
size_t memsize;
unsigned char *ptr;
if (argc > 1) {
unsigned long tmp;
errno = 0;
tmp = strtoul(argv[1], NULL, 0);
if (tmp == ULONG_MAX && errno == ERANGE) {
puts("Value too large...");
exit(EXIT_FAILURE);
}
else memsize = (size_t)tmp;
}
else memsize = (size_t)DEFAULT_SIZE;
printf("Attempting to allocate %lu bytes...\n",
(unsigned long)memsize);
ptr = malloc(memsize);
puts("Press Enter to proceed:");
getchar();
free(ptr);
puts("Press Enter to exit:");
getchar();
return EXIT_SUCCESS;
}
$ gcc -Wall -Wextra -ansi -pedantic -o t1 t1.c
$ ./t1 1000000000
Attempting to allocate 1000000000 bytes...
Press Enter to proceed:
Here is the output of 'ps aux | grep t1'
santosh 28617 0.0 0.0 977984 396 pts/2 S+ 07:29 0:00 ./t1
1000000000
Press Enter to exit:
Here is the output of the same command after free had been called:
santosh 28617 0.0 0.0 1420 396 pts/2 S+ 07:29 0:00 ./t1
1000000000
$
As you can see, memory is indeed "given back" to the OS after it has
been deallocated. Granted this may not happen for smaller amounts, but
this seems to happen at least with glibc and probably most other
implementations as well.
If the majority of implementations do in fact do this, then I'd say that
it is the Standard that may need to be modified rather than force
inconvenient behaviour on systems, something that C goes to great
lengths to avoid.
<snip>
I
Ian Collins
According to your interpretation of the somewhat ambiguous phrase "madeKelsey said:
available for further allocation".
R
Richard Heathfield
Ian Collins said:
....which is a perfectly reasonable interpretation, and one that I would
fully expect implementors to support. (Whether my expectations are
actually met in the Real World is an entirely different matter!)
....which is a perfectly reasonable interpretation, and one that I would
fully expect implementors to support. (Whether my expectations are
actually met in the Real World is an entirely different matter!)
I
Ian Collins
It may be a reasonable interpretation, but it isn't definitive. SoRichard said:
Kelsey's answer can't claim to be "The proper answer", merely one
possible answer.
S
santosh
Ian said:
A literal reading of the Standard's text supports Kelsey's
interpretation, but in practise I'd expect significantly sized
deallocations to be handed back to the OS, if there was a means to do
so. *I* wouldn't want to use any implementation that fails to return
deallocated memory of significant size (say 100 Mb) back to the OS, if
at all possible. It's poor QoI and selfish behaviour in a timesharing
environment.
However such behaviour may be perfectly acceptable under single user,
embedded and realtime systems. This is why, I suspect, the Standard has
declined to specify a concrete behaviour and intentionally left the
wording neutral.