Date: Sat, 16 Sep 1995 10:14:46 -0700 From: Paul Traina <pst@shockwave.com> To: Poul-Henning Kamp <phk@freefall.freebsd.org> Cc: CVS-commiters@freefall.freebsd.org, cvs-lib@freefall.freebsd.org Subject: Re: cvs commit: src/lib/libc/stdlib Makefile.inc malloc.3 malloc.c free.3 realloc.3 Message-ID: <199509161714.KAA00186@precipice.shockwave.com> In-Reply-To: Your message of "Sat, 16 Sep 1995 02:28:19 PDT." <199509160928.CAA09720@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am I blind, or was there no discussion or code review of this in current or
committers first?
Malloc/free/sbrk is one of those areas where EVERYONE thinks they can do
a better job, and usually they end up screwing up. I don't want a faster
malloc(), I want one that's not going to break.
There are a bunch of programs that break with gnumalloc(), and that's gotten
years of pounding on by a large community. I am extremely unhappy that you've
taken it upon yourself to change one of the most complicated and central
library functions in FreeBSD without a long testing period by dozens of
people and with no way to back out.
My suggestion is to back out this change immediately, and create a libpmalloc.a
library that you and others who wish to use your malloc may use.
Consider me really really really pissed. This isn't a game or anyone's
personal system.
Paul
From: Poul-Henning Kamp <phk@freefall.freebsd.org>
Subject: cvs commit: src/lib/libc/stdlib Makefile.inc malloc.3 malloc.c free.
>>3 realloc.3
phk 95/09/16 02:28:15
Modified: lib/libc/stdlib Makefile.inc malloc.3 malloc.c
Removed: lib/libc/stdlib free.3 realloc.3
Log:
``phkmalloc''
Performance is comparable to gnumalloc if you have sufficient RAM, and
it screams around it if you don't.
Compiled with "EXTRA_SANITY" until further notice.
see malloc.3 for more details.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509161714.KAA00186>