malloc vs ptmalloc2
peadar.edwards at gmail.com
Mon Feb 14 08:50:23 PST 2005
On Mon, 14 Feb 2005 08:04:50 -0500, David Schultz <das at 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.
More information about the freebsd-hackers