From owner-freebsd-current  Fri Sep 22 05:49:22 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id FAA28069
          for current-outgoing; Fri, 22 Sep 1995 05:49:22 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA28063
          ; Fri, 22 Sep 1995 05:49:19 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.12/8.6.9) id FAA27600; Fri, 22 Sep 1995 05:49:03 -0700
Date: Fri, 22 Sep 1995 05:49:03 -0700
Message-Id: <199509221249.FAA27600@silvia.HIP.Berkeley.EDU>
To: nate@rocky.sri.MT.net
CC: roberto@keltia.Freenix.FR, nate@rocky.sri.MT.net,
        freebsd-current@FreeBSD.org, rich@FreeBSD.org
In-reply-to: <199509211659.KAA02299@rocky.sri.MT.net> (message from Nate Williams on Thu, 21 Sep 1995 10:59:18 -0600)
Subject: Re: XFree86 and the new malloc
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: owner-current@FreeBSD.org
Precedence: bulk

Don't know if Rich is listening to -current, so let me comment on this.

 * Basically, the stock BSD malloc caused a number of programs to be less
 * useful than they were if compiled against GNU malloc.

The largest (literally) example was the X server.  My 3.1.1 XF86_S3 in
16-bit mode routinely grew over 20MB and it was, um, very annoying, to
say the least.  With gnumalloc, it rarely goes over 10MB.  Ditto for
xv.  With the old libc malloc, there really wasn't much choice but to
use gnumalloc.

We'll have to test how phkmalloc works, and see what we should
recommend them for 3.1.3 (or 3.2?).  I'm going to compile the X server
with phkmalloc tomorrow (I'm doing a make world now) and let you guys
know if something goes "puff" or "bloat".

Satoshi