From owner-freebsd-current@FreeBSD.ORG Tue Nov 29 16:56:50 2005 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A5F016A422 for ; Tue, 29 Nov 2005 16:56:50 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38F5C43D5A for ; Tue, 29 Nov 2005 16:55:40 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id D2D605E48B0; Tue, 29 Nov 2005 08:55:36 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 1C9665E48B0; Tue, 29 Nov 2005 08:55:34 -0800 (PST) In-Reply-To: <438C3D7C.3000704@portaone.com> References: <438C3D7C.3000704@portaone.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A7D4B98-9474-42B6-8A21-4C9AB8582EC1@canonware.com> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Tue, 29 Nov 2005 08:55:13 -0800 To: Maxim.Sobolev@portaone.com X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@FreeBSD.ORG Subject: Re: New libc malloc patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2005 16:56:50 -0000 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