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

 
 
Micah Cowan
Guest
Posts: n/a
 
      02-28-2008
Kelsey Bjarnason wrote:
>> Your refusal to accept the
>> others' interpretation as reasonable is unreasonable;

>
> On the contrary, it is perfectly reasonable, as they have yet to give any
> justification for this magical intrusion of the rest of the world into
> the operation of free, contrary to the dictates of the standard, and
> apparently alone of all the standard library functions.


Whether or not the interpretation opposing yours is reasonable, as I've
already pointed out elsethread (hoping, futilely apparently, that it
would finally kill this thread), the standard's _authors_ have declared
it as being the acceptable one. Therefore, whether reasonable or not,
that is how this text _must_ be interpreted.

Given that fact, please feel free to gripe that the standard's language
is completely inappropriate for that interpretation (preferably not
here, though) - I will quite agree. It doesn't change the fact, though,
that the matter has already been firmly resolved; continuing to assert
your interpretation informally (as opposed to asking the committee to
please fix the text) is therefore tantamount to being a sore loser.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
 
Reply With Quote
 
 
 
 
muntyan@gmail.com
Guest
Posts: n/a
 
      02-28-2008
On Feb 28, 11:38 am, Kelsey Bjarnason <(E-Mail Removed)> wrote:
> On Thu, 28 Feb 2008 12:33:16 +0000, Richard Bos wrote:
> > Kelsey Bjarnason <(E-Mail Removed)> wrote:

>
> >> On Wed, 27 Feb 2008 10:19:59 +0000, Richard Bos wrote:

>
> >> > Kelsey Bjarnason <(E-Mail Removed)> wrote:

>
> >> >> On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:

>
> >> >> > Kelsey Bjarnason <(E-Mail Removed)> 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.

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

>
> >> > There is none. Your interpretation of "as the standard defines it" is
> >> > wrong.

>
> >> You keep saying that, why is it you seem unable to demonstrate it?

>
> > It's been explained several times, but you refuse to accept it.

>
> > One (one last!) more time:

>
> > Your interpretation of "for further allocation" as "for futher
> > allocation by the current program alone" is a reasonable one.

>
> Since the very thing whose behaviour is being defined is the C program,
> it is the *only* relevant context in which to define the behaviour.
>
> > Others'
> > interpretation of "for further allocation" as "for futher allocation by
> > any program" is also a reasonable one.

>
> Except that this ignores the very reason for the standard, which is *not*
> to define behaviours of "any program".


Exactly, it defines the behavior of strictly conforming programs.
So provide an example of a strictly conforming program whose
behavior can be affected by malloc() giving memory back to OS
(and yes, failing to allocate that big block again) or stop
waving the standard like a flag. Note the "example of a strictly
conforming program" part. Everybody heard already that the standard
says there in black and white... not toasters and cars... etc.
 
Reply With Quote
 
 
 
 
muntyan@gmail.com
Guest
Posts: n/a
 
      02-28-2008
On Feb 28, 12:18 pm, Kelsey Bjarnason <(E-Mail Removed)> wrote:
> [snips]
>
> On Wed, 27 Feb 2008 17:22:37 -0800, ymuntyan wrote:
> >> > To make it easier for you, here's a simpler example: objects are
> >> > stored in toasters which are delivered to the program in cars when it
> >> > calls malloc(), and are carried away when the program calls free().

>
> >> No, they're not; if this occurred, the implementation cannot meet the
> >> behaviour mandated by the definition of free, as the car may not
> >> return. Thus the objects - the blocks of memory - are not allowed to be
> >> carried away when free is called.

>
> > Why? They will be brought back

>
> No; they *may* be brought back. They may not be. No such allowance is
> made; the requirement is that they *are*.
>
> >> The definition of free says *nothing* about the memory being made
> >> available for later allocation *if available* or *if not consumed by
> >> some other process*. There is zero - *zero* - allowance in the wording
> >> for any wiggle room whatsoever.

>
> > As well as there is zero guarantee about very next call to malloc(). All
> > you know is that it may fail.

>
> Correct, it may. It may _not_, however, fail because the implementation
> chose to hand the memory freed back to the OS. The standard forbids
> this, meaning that a failure in a subsequent allocation (of the same or
> lesser amount of memory) is at best a QoI issue, at worst a bug, whereas
> handing the memory back to the OS such that the OS might re-use it is not
> merely a QoI issue or a bug, but a non-conforming behaviour.
>
> >> I make no such assumption, and nothing I've said thus far requires such
> >> an assumption. The standard says the memory is made available for
> >> further allocation, it does not say when - it could be next Tuesday.

> > Yep. And a strictly conforming program can't know when that is going to
> > happen.

>
> Not quite the point, though, is it? It knows the memory _will_ be
> available, whereas if the memory is handed off to the OS for use outside
> the scope of the program, the guarantee is violated.
>
> > No, the point is that a strictly conforming program can't possibly know
> > whether it's still Monday or that implementation gave the memory back to
> > OS. So no strictly conforming program can demonstrate that this
> > implementation gave memory back to OS.

>
> It doesn't need to. Try the following:
>
> void *ptr = malloc( 1000 ); /* this one worked, error checked omitted */
> free( ptr );
> ptr = NULL;
>
> while ( ptr == NULL )
> {
> ptr = malloc( 100 );
>
> }
>
> According to the standard, this program should fall out of the loop at
> some point, whether today or tomorrow or next week, as the memory has
> been allocated once, freed, thus made available.
>
> The only cases where this is not true are:
>
> 1) Where the implementation's memory management is so bad it can't
> allocate a 100-byte pool from a reserved 1,000-byte arena
>
> 2) Where the implementation's memory manage is so bad that the overhead
> of the subsequent allocations exhaust the pool of previously allocated
> memory
>
> 3) The implementation does something really asinine, such as handing the
> memory back to the OS, such that it can no longer guarantee the program
> will behave in a manner defined by the standard.
>
> The first two are QoI issues, the latter is nothing less than a non-
> conforming implementation.


You just said yourself that your program is not strictly
conforming - 1) and 2) cases (so this is not an example
I asked for in another post).
There are other cases when malloc() could fail there,
but it's not important, we can just agree that malloc()
can legally fail for whatever reason, be it 1), 2) or 1

[snip]
> If dynamic memory allocation _is_ part of a strictly conforming program,
> then the behaviour of free is strictly curtailed; the loop above *must*
> terminate.


Yes, malloc() and free() can be parts of a strictly conforming
program. But if a program output depends on whether implementation
gives memory back to the OS, then it's not strictly conforming.
See 1) and 2).

Yevgen
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-29-2008
Kelsey Bjarnason <(E-Mail Removed)> writes:
> [snips]
> On Thu, 28 Feb 2008 02:56:07 +0000, Gordon Burditt wrote:
>
>>>And this has *what* to do with the price of tea in China?

>>
>> free() may return memory from the C program to the OS

>
> Only if it can guarantee the OS will somehow tag that memory as reserved
> for the C program. Otherwise, it cannot. Read the definition of free;
> there is no allowance for handing the memory back to the OS in the
> general case, as that would risk making the memory *not* available for
> further allocation.


Proof by repetition?

--
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
 
Richard Bos
Guest
Posts: n/a
 
      02-29-2008
Kelsey Bjarnason <(E-Mail Removed)> wrote:

> Do, please, show me


No. You cannot be shown anything while your eyes and mind are closed.

Goodbye.

Richard
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-29-2008
Kelsey Bjarnason <(E-Mail Removed)> writes:

> On Thu, 28 Feb 2008 12:33:16 +0000, Richard Bos wrote:
>
>> Kelsey Bjarnason <(E-Mail Removed)> wrote:
>>
>>> On Wed, 27 Feb 2008 10:19:59 +0000, Richard Bos wrote:
>>>
>>> > Kelsey Bjarnason <(E-Mail Removed)> wrote:
>>> >
>>> >> On Tue, 26 Feb 2008 07:25:14 +0000, Richard Bos wrote:
>>> >>
>>> >> > Kelsey Bjarnason <(E-Mail Removed)> 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.
>>> >> >
>>> >> > 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
>>> >
>>> > There is none. Your interpretation of "as the standard defines it" is
>>> > wrong.
>>>
>>> You keep saying that, why is it you seem unable to demonstrate it?

>>
>> It's been explained several times, but you refuse to accept it.
>>
>> One (one last!) more time:
>>
>> Your interpretation of "for further allocation" as "for futher
>> allocation by the current program alone" is a reasonable one.

>
> Since the very thing whose behaviour is being defined is the C program,
> it is the *only* relevant context in which to define the behaviour.


I have been sitting on my hands with this thread, but I can't any
longer. Your basis for this is that the standard only considers one
program, that there is no "OS" so how else can one interpret "being
available"?

You miss the fact that there *is* another entity here, but only by
implication. It seems reasonable to me to interpret "available for
further allocation" as returning the memory to the place it came from.
malloc does not create the memory, it "allocates" it. This implies a
sort of change of ownership from some other entity (the OS, of course)
to the program. An allocation is an assignment, from one entity to
another. Making memory "available for further allocation" could be
taken to mean the memory reverts to the state (of ownership) that it
had before.

I don't expect you to be persuaded -- I think you have decided what
the phrase means, but I don't think your argument is as watertight as
you believe it to be. I won't press this point because the thread is
long enough already and the matter is resolved for all practical
purposes.

--
Ben.
 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      02-29-2008
Kelsey Bjarnason <(E-Mail Removed)> wrote:
>
> Show me where, in the standard's definition of free, it allows *any* form
> of implementation-defined behaviour or the like which allows free to
> return the memory back to the OS in the manner you describe.


The committee has discussed this issue in the past and the consensus was
that returning the memory to the OS *does* make it available for future
allocation. The fact that it may not remain available for very long is
outside the scope of the standard, as is the amount of memory that is
available for allocation at any particular point in time.

-Larry Jones

I like Mom to be impressed when I fulfill the least of my obligations.
-- Calvin
 
Reply With Quote
 
Herbert Rosenau
Guest
Posts: n/a
 
      03-01-2008
On Thu, 28 Feb 2008 17:33:49 UTC, Kelsey Bjarnason
<(E-Mail Removed)> wrote:

> [snips]
>
> On Thu, 28 Feb 2008 02:56:07 +0000, Gordon Burditt wrote:
>
> >>And this has *what* to do with the price of tea in China?

> >
> > free() may return memory from the C program to the OS

>
> Only if it can guarantee the OS will somehow tag that memory as reserved
> for the C program. Otherwise, it cannot. Read the definition of free;
> there is no allowance for handing the memory back to the OS in the
> general case, as that would risk making the memory *not* available for
> further allocation.
>

In contrary to your false assumption there is nothing in the standard
that forbids to give back borrowed memory to the OS and request it
from there again when needed.

When there were really a request on the implementation to give never
any memory back to the OS it were mostenly implossible for the
implementation to fullify many requests of different sizes after some
requests are freed.

When your implementation runs in an environment where the memory is
based on virtual addresses and a single memory block must be virtually
continous even it is really not then only the OS knows how to build a
virtual block of continous virtual memory of requested size.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
 
Reply With Quote
 
Herbert Rosenau
Guest
Posts: n/a
 
      03-01-2008
On Wed, 27 Feb 2008 17:22:27 UTC, Kelsey Bjarnason
<(E-Mail Removed)> wrote:

> [snips]
>
> On Wed, 27 Feb 2008 00:27:10 +0000, Gordon Burditt wrote:
>
> > Tell me what prohibits this implementation:

>
> [irrelevances snipped]
>
> > A C program may free memory and the implementation may return it to the
> > OS. The OS may then let a non-C program (or a C program running in
> > non-standard-compliant mode)

>
> Non-conforming mode? Yes, well, you just answered your question: you're
> using a non-conforming implementation, which means it's either broken, or
> non-conforming by intent; if the former, file a bug report. If the
> latter, consider it a QoI issue.
>


Come on, where in the standard is defined that the abstract mashine it
describes has to know of what a program is and which behavior this
program - when it exists - has to have?

Fact is that the standard says nothing about program, nothing about an
OS, nothing about real memory, nothing about files, nothing about any
real device. It defines only an abstract mashine and its behavior from
sight of C.

The standard defines explicity the interface between the C environment
and a program - when there is at least a single program (hosted) but
it lets open anything for freestanding environments. It says nothing
about memory that is on hosted environment outside the environment, it
says not even that malloc will be able to get memory from somewhere
outside the singe program. That means from your side that malloc can
never be able to request memory from an OS it runs under because it
can't exist or is always and under all circumstance unrequestable. So
you're right. What can't requested can't freed.

From your sight a program will always be unable to open a file, it
can't read or write a file, it can't remove a file too. Because the
standard tells only about streams. A stream is as the standard
describes is something abstract that gets magically data from
somewhere and delivers data magically to somewhere.

So, however an implementation can request memory for dynamic
allocation from outside the program it must be able to release it when
the program tells it that the memory is unused now. When an
implementation is unable to fullify such request because the
underlying OS can not do it, it will not even try it.

The standard simply does not distinguish between environments who are
able to borrow memory from outside the program and such who are abe to
because it needs the freedom to live this to the real environment
completely.

When you needs to know what your implementation can do to fullify a
request for dynamic allocated memory and what it will do when there is
a block of memory available to give back to the OS when it was gotten
from it then you'll have to look into the documentation of your
implementation what goes on. As the standard does not require that
this behavor has to be docomented completely there may or may not
about that documented a bit, or more or less complete.

A good designed implementation will hold a basic block of free memory
to give away through m|c|realloc for the whole runtime of the program
and borrow more from the OS so long the program needs that and give
back the borrowed memory back when possible.



--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
 
Reply With Quote
 
Herbert Rosenau
Guest
Posts: n/a
 
      03-01-2008
On Wed, 27 Feb 2008 00:53:19 UTC, Kelsey Bjarnason
<(E-Mail Removed)> wrote:

> Thus, for example, one need not have a specific clause which disallows
> the pre-increment operator to produce a result of 19,471 from a previous
> value of 3; it is sufficient to have a definition of how pre-increment is
> defined to work, plus the rules for determining what to expect: the
> behaviour is defined _thus_, any implementation which does otherwise is
> non-conforming.


Yes, no!. Increment and decrement is well specified by the standard.
For variables are not pointers it is always 1. For pointers it is
always the number of bytes + padding bytes the object the pointer
points to.

> Therefore, by defining a behaviour for free, the standard defines what
> free is expected to do, how it is expected to behave.


No, it does this only partially. It does not specify
- should a single block coming back from the program
concated into the 2 neighbour blocks already free
- should a single block coming back from the program
live free for only allocated in the same or less size
- should a memory block borrowed from the OS should
be given back to the OS when this block is completely
fee again
- says nothing about that malloc can only be a wrapper
to an OS fuction that gives only memory in size of
(requested size in bytes + 1GB) / 1GB or not

It only requests explicity that a block that comes in from free should
NOT holded in use anymore but has to be given free for further
allocation for any c|m|realloc from who ever.

It does not specifiy the behavior of malloc
- should malloc request none, one, multiple blocks
of memory to fullify requests from the program
- should malloc only request memory from the OS
when the program stars up or should it do so
whenever it runs out of memory to fullify the
request of a single call when it receives one
or should it request a much larger block and
deliver this partieally?
- it does neither allow nor deny to give block of the
multiple size of the requested one out.

It does not specify the behavior of realloc completely.
- should shrinking the block result always or
noways result in moving the block around
- should expanding the block allow
- request another block from the OS or not
- compacting the list of free block to build
at least one that is big enough to hold
enough bytes

The up-front rules
> about interpreting the behaviour do not need to expressly disallow the
> case you mention, as the defined behaviour of free does not include such
> a case *nor* does it include any allowance for implementation-defined
> behaviour or the like; it behaves as documented, or the implementation
> fails to meet the requirements of the standard and thus is non-conforming.
>
> And what *is* the defined behaviour? Right - to make the memory
> available for further allocation.


Sure - it does simply not allow to block the block for ever. It does
NOT forbid to give the block complete or partially back to the OS.

> Ah, but wait. To *whom* does it define this behaviour? Is the C
> standard suddenly the defining document for POSIX-based OSen? How about
> non-POSIX-based OSen? How about process management in general? Cars?
> Toaster ovens?
>
> Nope, none of these apply. The behaviour defined is the contract between
> implementation and developer, in the context of writing C programs to be
> used in conjunction with a C implementation. That is *it*. No OSen, no
> cars, no toaster ovens, just C, all C, nothing but C.


That it's! The block should no more blocked from allocation, it should
given away again. But not only to this program but maybe even to
another one - saying nothing about
- the block can be splitted to allow lesser requests or not
- the block can combined with neighbar ones to build one that
is bigger than the original one
It says only "don't block that block" anymore until it is given away
again.



--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 
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