Memory profiler for shotodol framework

C programming language does not come up with garbage collector. It is not object oriented. But C is inevitable. C programs are portable into different platform. A lot of libraries and server applications are written in C. The Aroop compiler gives the developer flexibility to write object oriented Vala code that can generate C code. Likewise it is also possible to use existing C library in Vala code.

So Aroop is the source-to-source compiler. It compiles Vala code into C. The Aroop compiler is a fork of original Vala compiler. The Vala compiler generates code that uses the GObject library to represent the Object data. On the contrary the Aroop uses object pools.

Shotodol is an application framework based on Aroop compiler. It has instrumentations for memory profiling, dependency injection and more. In this blog we will disect the memory profiling feature.

The profiler can give the memory usage of specific module, it can dump existing string allocations and more.

help prof
Executing:help prof
<            help> -----------------------------------------------------------------
SYNOPSIS:
    profiler
         -heap          <none>  Show all the memory allocated in all the factories
       -string          <none>  Dump the string buffers
       -object          <none>  Show the objects
       -module          <text>  Select/filter out a module
<      Successful> -----------------------------------------------------------------

For example, if we investigate the memory usage of “core/console” module, we get the following.

prof -module core/console
Executing:prof -module core/console
<        profiler> -----------------------------------------------------------------
Source               Line  Module     -- pools      allocated  used       objects    slots      bitstring  pool size 
vsrc/ConsoleCommand.  2116 core/conso --          0          0          0          0          0         56         16
vsrc/ConsoleCommand.   954 core/conso --          0          0          0          0          0         56         16
vsrc/ConsoleCommand.   804 core/conso --          1      13792       8560         10         10         56         16
13792 bytes total, 8560 bytes used
<      Successful> -----------------------------------------------------------------

The table above says the line number where the memory pools are created. “vsrc/ConsoleCommand.c” is the generated C source. The pool allocates 16(it is set when the pool is created) slots at a time. Each slot size is assigned when the pool is created. The first two rows say that the pool is empty. The last row says that it contains 10 objects taking total 8KB space while the pool has 13KB(16 slots) allocated. And it says there is only one pool.

The profiling helps to set the optimal pool size. In optimal condition the pool does not waste too much unused memory and there is less system-call for malloc for pool creation.

It also identifies the memory leak or circular refernce that can invalidate garbage collection. This feature is particularly useful in the server application. In that scenario memory-leak is not desirable at all.

I hope to describe other shotodol features in the future. I just like to explain what the cool things it does.