Re: A solution for the allocation failures problem

Kelsey Bjarnason wrote:
[snips]

On Tue, 12 Feb 2008 16:09:24 -0500, Kenneth Brody wrote:

(It was actually Keith Thompson, but the attributions have
been mangled. Or perhaps reallocated ...)

Over in comp.std.c, Doug Gywn, a member of the ISO C committee, has
said that memory deallocated by free() can be reclaimed by the OS (you
can find the article for his exact words). I'm not saying his
statement has the force of law, but it does imply something about the
intent. In my opinion, the words of the standard are uncomfortably
ambiguous, but they are consistent with the intent.
I think this is a case for comp.std.c's input, though I am hardly an
expert in such matters.

He said it; he couldn't thus far show where, in the standard, this behaviour is allowed.

You may notice that in several places the Standard restricts
the behavior of the implementation w.r.t. library functions that
have internal state. "The implementation shall behave as if no
library function calls the rand function," and similarly for
srand and getenv and setlocale and various others.

You may also notice that the Standard does *not* similarly
restrict the implementation's use of malloc. That is, the
implementation is permitted to allocate dynamic memory when it
feels like doing so, holding on to it as long as it likes, and
freeing or not freeing it at its own whim. It seems likely
that fopen might well allocate some buffers and things, and it
seems all but certain that setvbuf would do so if passed a null
pointer.

The implementation might use dynamic memory for auto variables,
particularly for C99's variable-length arrays. That is, the
implementation might choose to allocate memory even when there's
no overt library function call in the vicinity.

The upshot is that it's difficult if not impossible to tell
that an implementation has failed to make freed memory "available
for further allocation." You can free a bunch of memory and turn
right around and try to allocate it again and discover that the
allocation attempt fails, but from this you cannot conclude that
the implementation has misbehaved. Some hard-to-see piece of the
implementation may have already taken advantage of the memory's
availability and allocated it for the implementation's own use,
making it unavailable to an ordinary malloc call, and this would
be entirely legal.

In short, even if we read the Standard as imposing such a
requirement, the requirement is untestable and hence without
force. An implementation that deliberately refused to re-use
freed memory, or which imposed a delay between the freeing and
any reallocation (as a debugging aid, say) could not haled into
court and convicted: it would still have "plausible deniability"
to any charge you might bring against it. If the requirement
exists, it might as well not.

--
Eric.Sosman@xxxxxxx
.

Relevant Pages

  • Tru64 issues with Infinite limits
    ... An automated test in my nightly build was failing due to Out of Memory ... Cannot allocate block 146 ...
    (comp.unix.tru64)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (comp.lang.cpp)
  • Re: Sharing memory between kernelspace and userspace
    ... deallocate, on a totally dynamic basis, userspace ... Let userspace allocate shared memory visible to multiple ... and pass that into the kernel for it to write to. ...
    (Linux-Kernel)
  • Re: [ckrm-tech] RFC: Memory Controller
    ... I'd pay more attention to kernel memory accounting and less ... How would you allocate memory on NUMA in advance? ...
    (Linux-Kernel)