Date: Tue, 29 Nov 2005 08:55:13 -0800 From: Jason Evans <jasone@canonware.com> To: Maxim.Sobolev@portaone.com Cc: current@FreeBSD.ORG Subject: Re: New libc malloc patch Message-ID: <1A7D4B98-9474-42B6-8A21-4C9AB8582EC1@canonware.com> In-Reply-To: <438C3D7C.3000704@portaone.com> References: <B6653214-2181-4342-854D-323979D23EE8@canonware.com> <438C3D7C.3000704@portaone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1A7D4B98-9474-42B6-8A21-4C9AB8582EC1>