Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Freeing memory - will it be available immediately

Reply
Thread Tools

Freeing memory - will it be available immediately

 
 
Jack Klein
Guest
Posts: n/a
 
      02-26-2008
On Mon, 25 Feb 2008 13:54:54 -0800, Kelsey Bjarnason
<(E-Mail Removed)> wrote in comp.lang.c:

> [snips]
>
> On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
>
> > 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.

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


Chapter and verse, please, I insist. What wording in the C standard
prohibits free() from returning memory to the operating system?

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


It is not implementation-defined, it is indeed unspecified. The one
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.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      02-26-2008
On Tue, 26 Feb 2008 08:44:13 +0530, santosh <(E-Mail Removed)>
wrote in comp.lang.c:

> Ian Collins wrote:
>
> > Richard Heathfield wrote:
> >> 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!)
> >>

> > It may be a reasonable interpretation, but it isn't definitive. So
> > 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.


[snip]

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.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      02-26-2008
Kelsey Bjarnason <(E-Mail Removed)> wrote:

> On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
>
> > 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.

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


You keep opining that, and you continue to be wrong.

Richard
 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      02-26-2008
[snips]

On Mon, 25 Feb 2008 21:49:36 -0600, Jack Klein wrote:

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

>
> Chapter and verse, please, I insist. What wording in the C standard
> prohibits free() from returning memory to the operating system?


One needs to consider context. The C standard defines the behaviour of a
C program, which in turn means it also defines how the standard library
functions define _as relates to that C program_.

The definition of free says that the memory freed is made available for
further allocation.

Thus, in context, it defines, _for the C program_ that the memory remains
available; it cannot, therefore, hand it back to the OS, as the memory
would then _not_ be available for further allocation.

> It is not implementation-defined, it is indeed unspecified.


Actually, it is quite clearly defined, absolutely and unequivocally.

> The one 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?


Context. The standard is not defining the operation of toasters or
televisions, but of C programs and the library functions on which they
rely. It defines exactly such a behaviour for free: the memory is made
available for further allocation. By free, to the C program, the very
things whose behaviour is being defined.

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


The fact that this violates the defined behaviour of free, which makes
the memory available for reallocation, a behaviour defined in a document
whose sole reason for existence is to define behaviours of C programs.

> Since the standard does not define or constrain "further allocation",
> how can you claim it forbids the second example?


By noting the context in which the behaviour is defined, and a complete
absence of any clause or allowance for any behaviour *other* than what I
described.

 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      02-26-2008
On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:

> Kelsey Bjarnason <(E-Mail Removed)> wrote:
>
>> On Mon, 25 Feb 2008 16:43:10 +0530, santosh wrote:
>>
>> > 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.

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

>
> You keep opining that, and you continue to be wrong.


If I'm wrong, please point out the clause which allows the defined
behaviour to work other than as the standard defines it - you know, the
part where it says "implementation defined" or "undefined" or even
"unspecified" in the definition of free.

You can't; it's not there. What is there is a clear and absolute
definition of how free behaves in the context of a C program, the very
thing the standard exists to define. What is that behaviour? Oh, yes,
the memory is made available for further allocation. In what context?
Oh, yes, in the context of defining the behaviour of the C program.

It's pretty clear, there is, as far as I can tell, simply no other way to
read the definition of free, *in context*, and come to any other
conclusion.

You say I'm wrong? Fine; show me. Show me where the definition of free
gives it *any* allowance, via undefined, unspecified or implementation
defined clauses, to behave other than as the standard says it does.

 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      02-26-2008
On Tue, 26 Feb 2008 15:54:46 +1300, Ian Collins wrote:

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


The only ambiguity in the phrase is *when* the memory becomes available
for subsequent allocation. It could be immediately or six months from
now; the standard doesn't say.

What it does say is that the defined behaviour, in a document whose sole
reason to exist is to define how a C program is expected to work, is that
the memory is made available for further allocation. You know, to the C
program, the very thing whose behaviour is being defined.

If you can find a clause in the definition of free which allows for some
other behaviour, such as handing the memory back to the OS, please trot
it out; I can't find it anywhere.

 
Reply With Quote
 
Willem
Guest
Posts: n/a
 
      02-26-2008
Kelsey wrote:
) One needs to consider context. The C standard defines the behaviour of a
) C program, which in turn means it also defines how the standard library
) functions define _as relates to that C program_.

I believe this is the point of contention.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      02-26-2008
[snips]

On Mon, 25 Feb 2008 21:53:43 -0600, Jack Klein wrote:

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

>
> [snip]
>
> 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".



I assume you meant "does not say" there.

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


The C standard defines the expected behaviour of a C program.

The C standard, in order to do this, also defines the expected behaviour
of the standard library functions, behaviours on which that C program can
rely.

The C standard defines free as releasing the memory to be made available
for further allocation.

That's the defined operation _in the context of defining the operation of
a C program and the standard library on which it relies_. There is
nothing in that definition which allows for any other behaviour, such as
handing the memory back to the OS.

Nor, as noted elsewhere, does the "as-if" rule give us an out; failure to
make the memory available for further allocation (eg by giving it back to
the OS) is a direct violation of the text of the standard and cannot come
under the as-if rule; the as-if rule allows flexibility in conforming
behaviour, it does not allow non-conforming behaviour to take the place
of conforming.

Let's turn this on its head. You say "It most certainly does not say
'further allocation by the same program'". Very good. Explain, then,
exactly what the standard is defining the behaviour of, *if not the very
program under discussion*?

Of course it's defining the behaviour of the program and only the
program; it has no ability to define behaviours beyond that. It cannot
mandate that the system actually use a hard disk, or a monitor, it cannot
mandate that "text mode" universally means using "\r\n" so any other
applications or OSen better wake up; it defines one thing and only one
thing, the behaviour of the C program written against that standard.

In order to do so, in order to define the behaviour of the C program, it
*also* has to define the behaviours of the standard library, on which the
C program may rely. It does so, in the case of free: the memory is made
available for further allocation.

Not to the OS, not to your toaster oven, not to some other program, the C
standard has nothing to say on these matters. No, the only thing under
examination, the only candidate which the standard *can* define such
behaviours for, is the C program. It defines just such a behaviour, for
that program, and that definition absolutely precludes the notion of
handing the memory back to the OS; doing so violates the defined
behaviour of free.

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-26-2008
Kelsey Bjarnason <(E-Mail Removed)> writes:
> On Tue, 26 Feb 2008 15:54:46 +1300, Ian Collins wrote:
>> Kelsey Bjarnason wrote:
>>> On Mon, 25 Feb 2008 01:10:49 -0800, karthikbalaguru wrote:
>>>> 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".

>
> The only ambiguity in the phrase is *when* the memory becomes available
> for subsequent allocation. It could be immediately or six months from
> now; the standard doesn't say.
>
> What it does say is that the defined behaviour, in a document whose sole
> reason to exist is to define how a C program is expected to work, is that
> the memory is made available for further allocation. You know, to the C
> program, the very thing whose behaviour is being defined.
>
> If you can find a clause in the definition of free which allows for some
> other behaviour, such as handing the memory back to the OS, please trot
> it out; I can't find it anywhere.


Show us where the standard says that an implementation in which
storage deallocated by free() is made available for further allocation
by another program invoked via the standard system() function would be
non-conforming.

(For extra credit, construct a syntax diagram of that sentence.)

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      02-26-2008
[snips]

On Tue, 26 Feb 2008 08:44:13 +0530, santosh wrote:

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


Ooh, no, I would *not* want such a setup either. If I free memory, I
would much rather have it go back into the pool for all applications to
use; this strikes me as the most reasonable possible behaviour. It's
simply not a behaviour allowed by the standard.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
memory allocation and freeing memory Rodrigo Dominguez C Programming 11 06-14-2005 11:54 PM
freeing memory Harald Kirsch Java 0 04-22-2005 09:17 AM
freeing memory Rajesh.Rapaka Java 17 04-21-2005 10:11 PM
Freeing more Virtual Memory in Compaq Presario S4000NX Bun Mui Computer Support 2 05-22-2004 08:46 PM
some queries on freeing memory allocated using malloc Hassan Iqbal C Programming 3 09-25-2003 02:53 PM



Advertisments