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!