I have a question.

With the brk/sbrk tandem we have now, things like malloc() tend to grow
memory, and never release it because the things which get free()d
usually live above the brk(0) point by a large margin.

Is there even the REMOTEST chance that a large chunk of free()d memory
will actually be released back to the system for use, as in, say, the
various operations transpiring with e.g. the X server, so that it won't
be actually chewing up a 6MB++ RSS?

On Thu, 28 Feb 2002, David Laight wrote:

# Does the netbsd malloc still support:
# 	x = malloc( 20 );
# 	free( x );
# 	x = realloc( x, 10 );
#
# which is why it is called 'realloc'....

Actually, as I understand it, isn't realloc(ptr,size) supposed to
return a new pointer to region of size bytes something like this, below?

/* modulo error/memory boundary checks; I suppose there's a way
   to find the size previously requested by the old pointer. */

void *
realloc(void *oldptr, size_t newsize)
{
    void *newptr;
    size_t o;
    if ((newptr = malloc(newsize)) != (void *) NULL) {
	for (o = 0; o < newsize; o++) {
	    *(newptr + o) = *(oldptr +o);
	}
	free(oldptr);
    }
    return newptr;
}

# I don't actually see why there is a gain from using mmap() directly
# for malloc()?  The program data area is (effectively) an extensible
# area loaded from the program file (then zeros) that is written to
# swap.

There is no guarantee that the data area will be zeroed.

# An mmap()ed piece of /dev/zeros will be exactly the same.
# What you probably lose is address space fragmentation and memory
# fragmentation...
#
# 	David
#
# --
# David Laight: david@l8s.co.uk

				--*greywolf;
--
NetBSD: Servers' choice!