Date: Sun, 2 Apr 1995 05:08:49 +1000 From: Bruce Evans <bde@zeta.org.au> To: hackers@FreeBSD.org, vode@snakemail.hut.fi Subject: Re: Two proposals Message-ID: <199504011908.FAA18296@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> From malloc.c: > * This is a very fast storage allocator. It allocates blocks of a small > * number of different sizes, and keeps free lists of each size. Blocks that > * don't exactly fit are passed up to the next larger size. In this > * implementation, the available sizes are 2^n-4 (or 2^n-10) bytes long. > * This is designed for use in a virtual memory environment. > So if you malloc(1024) the overhead is another 1024 bytes.. I think it > is quite common to malloc 2^n or 2^n-1 bytes of memory (see almost any > WHATEVER_MAX in <limits.h>) so this is really stupid. It has also > some other shortcomings like not being able to coalesc returned memory. It seems to me that the kernel malloc() works very well. It uses power of 2 stuff up to a size of about 64K and separate storage for pointers so that allocations of 2^n don't get incremented up to the next power of 2. It uses vm features so that real memory doesn't get externally fragmented by more than one page size per (large) allocation). Only virtual memory gets fragmented. Can't the library malloc() use mmap() to avoid external fragmentation? Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504011908.FAA18296>