Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!ucbvax!rusty From: rusty@garnet.berkeley.edu (rusty wright) Newsgroups: comp.unix.ultrix Subject: Re: Memory ``leaks'' in DEC servers Message-ID: Date: 7 Mar 90 18:56:35 GMT References: <2973@bacchus.dec.com> Sender: usenet@ucbvax.BERKELEY.EDU Organization: /garnet_a/rusty/.organization Lines: 35 In-reply-to: joel@pandora.pa.dec.com's message of 7 Mar 90 01:15:45 GMT In article <2973@bacchus.dec.com> joel@pandora.pa.dec.com (Joel McCormack) writes: From: joel@pandora.pa.dec.com (Joel McCormack) Newsgroups: comp.unix.ultrix Subject: Memory ``leaks'' in DEC servers Date: 7 Mar 90 01:15:45 GMT Organization: DEC Western Research Laboratory (1) There is no way to give memory back to the kernel once it is allocated. So killing off all of your applications will not reduce the total amount of memory consumed by the server. It should reduce the amount of memory needed to be resident. This isn't true, a program can give memory back to the kernel once it is allocated; do "man brk". The problem is in the implementation of malloc, realloc, and free. Notice in the Ultrix man page for malloc, et. al. that for free it says The argument to free is a pointer to a block previously allocated by malloc. This space is made available for further allocation, but its contents are left undisturbed. I don't know why they do this, but I think it has something to do with realloc or old code that tries to do what realloc does using free and malloc. Presumably one could write a different free, that really frees the memory and returns it to the kernel via brk. Version 19 of gnu emacs is supposed to have something that does this; emacs also has a problem of growing without bound since it keeps the entire file in memory. -- -------------------------------------- rusty c. wright rusty@violet.berkeley.edu ucbvax!violet!rusty