From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 14 16:50:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA7F816A4CE for ; Mon, 14 Feb 2005 16:50:23 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41E8343D4C for ; Mon, 14 Feb 2005 16:50:23 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so1842074wri for ; Mon, 14 Feb 2005 08:50:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=aRI5SHl2QzTpXWHPjF0YjDOcG/CNfTmJ3VhndxzZmyqnmM1YaxPJZjo6c+5mavRBvY2ZTVwl/OTmSaIX3llIyPFB0292IQbnxLoYTTmRlvhDFSgkYeHSIXALHukh9CBzuxyXWUqXWjJYmjDh5v9V8XExdzlGeJNh1FrB19iJSyg= Received: by 10.54.28.44 with SMTP id b44mr91372wrb; Mon, 14 Feb 2005 08:50:22 -0800 (PST) Received: by 10.54.57.20 with HTTP; Mon, 14 Feb 2005 08:50:22 -0800 (PST) Message-ID: <34cb7c84050214085030a48cb6@mail.gmail.com> Date: Mon, 14 Feb 2005 16:50:22 +0000 From: Peter Edwards To: Andrew MacIntyre , Jason Henson , freebsd-hackers@freebsd.org In-Reply-To: <20050214130450.GA55300@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1108277558l.86500l.0l@BARTON> <20050213082128.GA68307@VARK.MIT.EDU> <42108243.9030800@bullseye.apana.org.au> <20050214130450.GA55300@VARK.MIT.EDU> X-Mailman-Approved-At: Tue, 15 Feb 2005 13:03:55 +0000 Subject: Re: malloc vs ptmalloc2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Peter Edwards List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 16:50:23 -0000 On Mon, 14 Feb 2005 08:04:50 -0500, David Schultz wrote: > Right, databases, language runtimes, and the small set of other > applications for which it really matters usually have their own > special-purpose allocators. I was counting on that when I said > that replacing malloc() is unlikely to make a big difference. > (One could argue, of course, that it's unfortunate that > applications need to do so.) I've worked on several heavily threaded applications that have benefitted greatly from either the introduction of a threads-conscious allocator, especially on MP machines, or sacrificing space for time and simplicity by having per-thread queues for commonly sized blocks of memory (ie, a "specialised allocator".) They have included language runtimes and databases, but also networking apps, and other server systems. An application can't assume it's master of the machine you run on, and dynamically sizing the app over time can be important. Long-running server applications may also have similar design goals the kernel deals with: by providing a generally fast allocator, different subsystems don't have to all have their own independent specialised heap allocators, causing fragmentation of memory in the long term. (But instead of having mbufs and other subsystem-specific structures, you've to deal with sharing your address space with third party libraries (A JVM and XML parsers, for example) I'm just saying don't be too quick to see heavy (as opposed to ridiculous) malloc/free use in applications as a design problem in userland apps when use of similar services in the kernel is encouraged over rolling your own allocators.