libumem

A reader asked for a simple rule when to use the multithreading friendly memory allocatorlibumem. I’m not that convinced of the need of such a simple rule. Given that plockstat is part of Solaris 10 and it gives you a extremly good insight into lock holds and lock contentions, just use it with your application. The more and the longer lock contention events you see with plockstat -C -p <PID></code< you see, the more you will benefit from libumem. But there is a simple rule-of-thump to find processes which are worthwhile targets for such an closer inspection: Whenever you have an application with more than one thread on a system with more than one core, it's worth a try. Of course the effect varies: When you have an application that allocates and frees memory all the time, the effect can be very substantial. I just found an application sitting 1,7 seconds of 10 time seconds in the libc_malloc_lock. But when you have an application preallocating large areas of memory at the start and doing only a few malloc/free calls further down the road, it won't yield that much additional speed. Java (especially at minheap=maxheap) is a good example for a such preallocating environment, however this is just half of the story: Your java application may use native libraries and those ones may benefit from libumem and the reduced lock contention on libc_malloc_lock. At the end: libumem is easy to use (LD_PRELOAD=libumem.so), it's in Solaris since Solaris 9 (so it's a matured piece of software), so it's worth a try in any case.

Additional information:

docs.sun.com: libumem(3LIB) - man page
c0t0d0s0.org - Less known Solaris error messages: “open failed: No such file in secure directories”