Skip site navigation (1)Skip section navigation (2)
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>