New libc malloc patch
Jason Evans
jasone at canonware.com
Tue Nov 29 16:56:50 GMT 2005
On Nov 29, 2005, at 3:37 AM, Maxim Sobolev wrote:
> Just curious what is the grand plan for this work? I wonder if it
> will make sense to have two malloc's in the system, so that user
> can select one which better suits his needs.
The plan for this work is to replace the current malloc, rather than
augmenting it. There is a long history in Unix of using shared
library tricks to override the system malloc, and the patch does not
change the ability to do so. However, in my opinion, explicitly
providing multiple implementations of malloc in the base OS misses
the point of providing a general purpose memory allocator. The goal
is to have a single implementation that works well for the vast
majority of extant programs, and to allow applications to provide
their own implementations when the general purpose allocator fails to
perform adequately. 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.
Jason
More information about the freebsd-current
mailing list