Libumem is a portable userland slab allocator. Originally available in Solaris operating system, it has been actively ported to other operating systems like OpenSolaris, Linux, Windows & particularly SmartOS.
The reason, why there is an emphasis on SmartOS is that, the original developers who were behind the revolutionary MDB , findleaks, ZFS ( Bryan Cantrill Gregory Burd) were part of the SmartOS. These people made a remarkable effort of bringing the magic of DTrace, Libumem & ZFS outside the proprietary gates of Oracle & made it very much accessible in opensource. Kudos to them.
DTrace is the most efficient diagnostic system, I have even seen in my little career. It has been so transparent that, even with absolutely zero knowledge about the inner implementations of the program, you can still understand what code-path the execution is taking, at this point of time. Brilliant architecture, I would say.
Over the period of time, many efforts have been done to mimic these gems of Unix Solaris to other conventional operating systems. Projects like DTrace4Linux Intel PIN are some examples.
Of all the most sought after solaris gems, my personal favourite was ( is / will be ) always Libumem.
Memory is always everything. Be it a keyboard driver, that reads the character input from your keyboard and make your thoughts echoed in internet or sophisticated multi-threaded server that serves multi-million transactions per second or your billing software that takes care of your accounts or the super-star of all the programs in the world, the operating system, all can be encapsulated in a 6 letter word called MEMORY.
Dealing with memory is always pretty challenging. Of all the memory challenges, fragmentation and diagnostic of the used / un-used memory is the most trickiest of everything. Libumem attempted to solve these 2 major challenge and the results were more than satisfactory.
Though modern memory allocators like TcMalloc, Hoard etc are available, to me it always looked like, libumem is undisputed in its simplicity, robust design & usability. Also these allocators were lying around for sometime, when Libumem had already captured the market. If you need more information, read the caveats section here.
So it is quite obvious to expect that, libumem should be ported to other conventional OSes too. Exactly for such reasons, libumem ports projects were started. You can look one such project here. As you can see, though the port to linux is successful, the only pain point with respect to Libumem is the non-availability of diagnostic tools ( MDB, findleaks, umem_verufy, umalog etc) in non-solaris systems ( Linux / Windows etc).
Being an debug enthusiast and lover of libumem, I wanted to ensure the usability of libumem in linux userland. I have taken up this as my hobby project here and had already started some work like ( Added support in the def of umem_bufctl_audit_t to record transaction… Added minimal support of transaction log [umalog] etc).
Only then I started to realize the fact that, why no port for MDB actually existed. This is because, MDB was actually part of bigger mother ship of DTRACE & Solaris internal framework. MDB already had mechanisms to poke into a process’s datastructure ( thanks to dtrace ) so it was fairly easy for the developers to build routines around the instrumentation for libumem. This was infact the basic intention after-all.
However in Linux, this is not the case. At the max, you can save as much of information about the libumem’s internal datastructure in some globally accessible heap. But memory instrumentation is something more than that right? For instance, consider the command umalog as follows.
dcmd umalog - display umem transaction log and stack traces
In-order to save the call-stack for every invocation of umem_alloc & umem_free, there is no native method available in linux, to reconstruct it from active process or core file.
That’s where, this project start to get more complicated and challenging. This also describes why Sun Solaris dominated the industry, while Linux was pretty much available free of cost.
So now, the problem statement has changed itself. Before trying to bring mdb like command, it is important to understand how to bring in certain diagnostic framework in linux. Only then, mimicing mdb like commands is possible.
As a first step, I should understand the basic diagnostic tool in linux – GDB. I will keep writing what I learn on dissecting GDB inch by inch and also keep the story-telling ON while I bring in the mdb framework in linux userland.
Until then… Say tuned.
kspviswa 