Re: New libc malloc patch

In message <1A7D4B98-9474-42B6-8A21-4C9AB8582EC1_at_canonware.com>, Jason Evans wr
ites:

>[...]  phkmalloc did an excellent job in this capacity  
>for quite some time, but now that we need to commonly support  
>threaded programs on SMP systems, phkmalloc is being strained rather  
>badly.  This isn't an indication that we need multiple malloc  
>implementations in the base OS; rather it indicates that the system  
>malloc implementation needs to take into account constraints that did  
>not exist when phkmalloc was designed.

The malloc phkmalloc replaced was written at some point in the
1980ies on a VAX, and more or less assumed the Vax was effectively
a single user machine and without effective paging algorithms.

Phkmalloc was written in 1994/5 where I had 4MB of RAM in my
"Gateway Handbook 486" and very strongly assumed that with the
RAM prices of the day, I could not afford an upgrade.

I gave a talk about phkmalloc at USENIX ATC 1998 in New Orleans.
One of the central points in the talk was that infrastructure code
should have regular service overhauls, to check that the assumptions
in the design is still valid.

In addition to assumptions phkmalloc makes which are no longer
relevant, there are many assumptions which should be made today
which phkmalloc is not aware of, multi-threading being but one of
them.  Cache line effects, pipeline prefetching, multi-cpu systems,
different VM system algorithms, larger address spaces etc etc etc.

Once Jason is done, I have no doubts that "jemalloc" will beat
phkalloc in all relevant benchmarking thereby neatly rendering any
discussion about having multiple mallocs in the tree pointless.

A big thank you from the author of phkmalloc to Jason for following
the service manual to the letter :-)

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.