From owner-freebsd-commit Mon Dec 11 06:28:35 1995 Return-Path: owner-commit Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA10618 for freebsd-commit-outgoing; Mon, 11 Dec 1995 06:28:35 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA10559 for cvs-all-outgoing; Mon, 11 Dec 1995 06:28:18 -0800 (PST) Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA10543 for cvs-lib-outgoing; Mon, 11 Dec 1995 06:28:16 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA10528 Mon, 11 Dec 1995 06:28:14 -0800 (PST) Date: Mon, 11 Dec 1995 06:28:14 -0800 (PST) From: Peter Wemm Message-Id: <199512111428.GAA10528@freefall.freebsd.org> To: CVS-committers, cvs-lib Subject: cvs commit: src/lib/libc/stdlib malloc.c Sender: owner-commit@FreeBSD.ORG Precedence: bulk peter 95/12/11 06:28:14 Modified: lib/libc/stdlib malloc.c Log: Change phkmalloc so that the page directory is now floating and allocated via mmap() up around the shared library area. Previously the directory was allocated from space from it's own memory pool. Because of the way it was being extended on processes with large malloced data segments (ie: inn) once the page directory was extended for some reason, it was not possible to lower the heap size any more to return pages to the OS. (If my understanding is correct, page directory expansion occurs at 4MB, 12MB, 20MB, 28MB, etc.) I was seeing INN allocate a large amount of short term memory, pushing it over the 28MB mark, and once it's transient demands hit 28MB, it never freed it's pages and swap space again.) I've been running this in my libc for about a month... Also, seperate MALLOC_STATS from EXTRA_SANITY.. I found it useful to call malloc_dump() from within INN from a ctlinnd command to see where the hell all the memory was going.. :-) I've left MALLOC_STATS enabled, as it has no run-time or data storage cost. Reviewed by: phk Revision Changes Path 1.7 +47 -29 src/lib/libc/stdlib/malloc.c