From owner-freebsd-hackers  Tue Apr 11 12:51:16 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id MAA02076
          for hackers-outgoing; Tue, 11 Apr 1995 12:51:16 -0700
Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA02067
          for <hackers@FreeBSD.org>; Tue, 11 Apr 1995 12:51:10 -0700
Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.10) id NAA10123; Tue, 11 Apr 1995 13:55:06 -0600
Date: Tue, 11 Apr 1995 13:55:06 -0600
From: Nate Williams <nate@trout.sri.MT.net>
Message-Id: <199504111955.NAA10123@trout.sri.MT.net>
In-Reply-To: Kai Vorma <vode@snakemail.hut.fi>
       "A better malloc() for FreeBSD" (Apr 11, 10:11pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Kai.Vorma@hut.fi, hackers@FreeBSD.org
Subject: Re: A better malloc() for FreeBSD
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> As I wrote about two weeks ago the BSD malloc isn't very
> space-efficient but wastes memory quite liberally. 
...
> I searched for better malloc implementations and found two good
> candidates:
> 
>   o CSRI malloc v1.17 by Mark Moraes
>   o malloc-2.5.3b by Doug Lea
> 
> Both mallocs are very space-efficient and performs coalescing on
> frees. The CSRI malloc is a bit slow and somewhat bloated (it does
> have hooks for debugging and some helper functions like strdup,
> emalloc, evalloc etc.). Doug Lea's malloc is very fast and simple so I
> choosed it.

Do you have some comparisons of the mallocs to see space vs. time
effeciency? I think the CSRI malloc has some tests you can run.

> I replaced the BSD malloc in libc with Doug Lea's malloc about week
> ago and recompiled all static programs in /bin and /sbin.  So far I
> have had only two problems:
> 
[ Sed problem already fixed ]

> 2) Originally I installed Doug Lea's malloc as stdlib/dlmalloc.c
>    and just commented out old malloc (gen/valloc.c, stdlib/malloc.c
>    and stdlib/calloc.c) from makefiles. Everything worked smoothly
>    until I tried to link something with static gnumalloc (linker
>    complained about multiple defined symbols _malloc etc. Why?) so I had
>    to replace the original stdlib/malloc.c with dlmalloc.c and comment
>    out calloc() and valloc() from it.

This is a 'feature' of the linker which I'm supposed to be working on. 
Actually, this is expected behavior given the constraints which the
run-time linker must operate under, and if you are *really* interested
send me private email and I can explain it when I have more time.

If we were to bring this in, the best bet is to break up dlmalloc.c into
malloc.c, valloc.c, and calloc.c the same as the BSD malloc routines.

This should avoid (I *think*) the linker errors.

Could you try that out and see if it works?
> I'd like to see Doug Lea's malloc integrated into libc at some
> point. I don't think it should go into 2.1 but how about -current
> after 2.1 is out?

I'm in agreement with you.  The current malloc implementation is very
fast, but I think replacing malloc would make the system faster since
there would be less swapping due to less memory use.

If you could get some hard numbers re: performance I think we might have
more to stand on when the time comes to integrate it into the system.


Nate