From owner-freebsd-hackers  Sat Apr  1 11:12:31 1995
Return-Path: hackers-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA25076 for hackers-outgoing; Sat, 1 Apr 1995 11:12:31 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA25059 for <hackers@freebsd.org>; Sat, 1 Apr 1995 11:12:19 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA18296; Sun, 2 Apr 1995 05:08:49 +1000
Date: Sun, 2 Apr 1995 05:08:49 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199504011908.FAA18296@godzilla.zeta.org.au>
To: hackers@FreeBSD.org, vode@snakemail.hut.fi
Subject: Re: Two proposals
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>  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