On Mon, 14 Feb 2005 08:04:50 -0500, David Schultz <[EMAIL PROTECTED]> 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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
