A reader asked for a simple rule when to use the multithreading friendly memory allocator
libumem. 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
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.