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
-
-
Re: Freeing memory - will it be available immediately
karthikbalaguru wrote:I believe Harold Pinter, when directing plays he wrote, would answerHi,
>
Will 'free' return the memory Immediately to the OS ?
questions about the characters, their motivation and so on by saying
"the text doesn't tell us"...
That's the answer here...
-
Re: Freeing memory - will it be available immediately
On 25 Feb, 09:10, karthikbalaguru <karthikbalagur ...@gmail.comwr ote:
usually no. In fact usually the memory is only returned to the OSWill 'free' return the memory Immediately 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
Comment
-
Re: Freeing memory - will it be available immediately
On Feb 25, 2:10 pm, karthikbalaguru <karthikbalagur ...@gmail.com>
wrote:No and yes, but usually no. The standard library implementation mayHi,
>
Will 'free' return the memory Immediately to the OS ?
>
Thx in advans,
Karthik Balaguru
not release the acquired memory to the OS. However, the program can
not use it anymore once freed.
Thanks,
Vijay Zanvar
Comment
-
Re: Freeing memory - will it be available immediately
On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
The proper answer is that, according to the text of the standard, itHi,
>
Will 'free' return the memory Immediately to the OS ?
*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.
Comment
-
Re: Freeing memory - will it be available immediately
[snips]
On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
Is it? I see nothing whatsoever in the definition of free which allowsI think you are misunderstandin g 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.
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 "implementa tion defined" in the definition of free, in a
manner which would allow the behaviour you describe, please quote it; I
cannot find it anywhere.
Comment
-
Re: Freeing memory - will it be available immediately
In article <e2qb95-og.ln1@spanky.l ocalhost.net>,
Kelsey Bjarnason <kbjarnason@gma il.comwrote:
>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.Those who didn't follow the recent thread on the subject should note>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.
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
--
:wq
Comment
-
Re: Freeing memory - will it be available immediately
Kelsey Bjarnason wrote:
I said implementation specific, not implementation defined, meaning[snips]
>
On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
>>>I think you are misunderstandin g 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.
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.
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_FAILU RE);
}
else memsize = (size_t)tmp;
}
else memsize = (size_t)DEFAULT _SIZE;
printf("Attempt ing 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>
Comment
-
Re: Freeing memory - will it be available immediately
Kelsey Bjarnason wrote:According to your interpretation of the somewhat ambiguous phrase "madeOn Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
>>>Hi,
>>
>Will 'free' return the memory Immediately to the OS ?
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.
>
available for further allocation".
--
Ian Collins.
Comment
-
Re: Freeing memory - will it be available immediately
Ian Collins said:
....which is a perfectly reasonable interpretation, and one that I wouldKelsey Bjarnason wrote:According to your interpretation of the somewhat ambiguous phrase "made>On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
>>>>>>Hi,
>>>
>>Will 'free' return the memory Immediately to the OS ?
>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.
>>
available for further allocation".
fully expect implementors to support. (Whether my expectations are
actually met in the Real World is an entirely different matter!)
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Comment
-
Re: Freeing memory - will it be available immediately
Richard Heathfield wrote:It may be a reasonable interpretation, but it isn't definitive. SoIan Collins said:
>>>Kelsey Bjarnason wrote:>According to your interpretation of the somewhat ambiguous phrase "made>>On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
>>>
>>>Hi,
>>>>
>>>Will 'free' return the memory Immediately to the OS ?
>>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.
>>>
>available for further allocation".
....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!)
>
Kelsey's answer can't claim to be "The proper answer", merely one
possible answer.
--
Ian Collins.
Comment
-
Re: Freeing memory - will it be available immediately
Ian Collins wrote:
A literal reading of the Standard's text supports Kelsey'sRichard Heathfield wrote:It may be a reasonable interpretation, but it isn't definitive. So>Ian Collins said:
>>>>>>Kelsey Bjarnason wrote:
>>>On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
>>>>
>>>>Hi,
>>>>>
>>>>Will 'free' return the memory Immediately to the OS ?
>>>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.
>>>>
>>According to your interpretation of the somewhat ambiguous phrase
>>"made available for further allocation".
>....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!)
>>
Kelsey's answer can't claim to be "The proper answer", merely one
possible answer.
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.
Comment
-
Re: Freeing memory - will it be available immediately
On Mon, 25 Feb 2008 13:54:54 -0800, Kelsey Bjarnason
<kbjarnason@gma il.comwrote in comp.lang.c:
Chapter and verse, please, I insist. What wording in the C standard[snips]
>
On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
>>I think you are misunderstandin g 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.
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.
prohibits free() from returning memory to the operating system?
It is not implementation-defined, it is indeed unspecified. The oneIf you can find "implementa tion defined" in the definition of free, in a
manner which would allow the behaviour you describe, please quote it; I
cannot find it anywhere.
and only statement in the standard that speaks about memory
deallocated by free() is (in C99) the first sentence of paragraph 2 of
7.20.3.2: "The free function causes the space pointed to by ptr to be
deallocated, that is, made available for further allocation."
What, in this wording, says that the space must be available for
further allocation by the program that free'd it?
What, in this wording, prohibits the implementation, which includes
the host OS in a hosted environment, from making that memory space
available to another process/program/component?
Since the standard does not define or constrain "further allocation",
how can you claim it forbids the second example?
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
Comment
-
Re: Freeing memory - will it be available immediately
On Tue, 26 Feb 2008 08:44:13 +0530, santosh <santosh.k83@gm ail.com>
wrote in comp.lang.c:
[snip]Ian Collins wrote:
>>Richard Heathfield wrote:It may be a reasonable interpretation, but it isn't definitive. SoIan Collins said:
>
>Kelsey Bjarnason wrote:
>>On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
>>>
>>>Hi,
>>>>
>>>Will 'free' return the memory Immediately to the OS ?
>>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.
>>>
>According to your interpretation of the somewhat ambiguous phrase
>"made available for further allocation".
>
....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!)
>
Kelsey's answer can't claim to be "The proper answer", merely one
possible answer.
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.
A literal reading of the standard's text says that allocated memory
properly free'd is made available for "further allocation". It most
certainly say "further allocation by the same program". Since the
term "further allocation" is not defined or constrained by the
standard in any way, where exactly does it forbid that further
allocation from being to another executable, process, device driver,
etc.?
As already said, Kelsey's interpretation is reasonable, but by no
means either guaranteed or required by the actual wording of the
standard.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
Comment
-
Re: Freeing memory - will it be available immediately
Kelsey Bjarnason <kbjarnason@gma il.comwrote:
You keep opining that, and you continue to be wrong.On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
>>I think you are misunderstandin g 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.
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.
Richard
Comment
Comment