Date: Mon, 14 Feb 2005 16:50:22 +0000 From: Peter Edwards <peadar.edwards@gmail.com> To: Andrew MacIntyre <andymac@bullseye.apana.org.au>, Jason Henson <jason@ec.rr.com>, freebsd-hackers@freebsd.org Subject: Re: malloc vs ptmalloc2 Message-ID: <34cb7c84050214085030a48cb6@mail.gmail.com> In-Reply-To: <20050214130450.GA55300@VARK.MIT.EDU> References: <1108277558l.86500l.0l@BARTON> <20050213082128.GA68307@VARK.MIT.EDU> <42108243.9030800@bullseye.apana.org.au> <20050214130450.GA55300@VARK.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Feb 2005 08:04:50 -0500, David Schultz <das@freebsd.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34cb7c84050214085030a48cb6>