Say hello to the smaps analyzer!

Based on the contents of /prod/<pid>/smaps, which is available on Linux,
we can make an educated guess about the contents of the process memory
of a JVM process, and tetris all little memory chunks into categories to
count the resident memory usage per category.

The m2ee munin plugin has been providing data to draw a graph about the
JVM memory usage for a long time. This graph gives insight in the
internals of the jvm heap generations, but it does not show memory usage
for the complete JVM process.

This code makes a few assumptions about how the world it's looking at is
organized:
 - Thread stack size is 1024kB, the default for 64bit linux. (or,
   actually 1016 kB and a 12 kB guard page).
 - The initial (-Xms) and maximum (-Xmx) JVM heap parameters have an
   identical value (so the heap memory block is directly fully
   allocated, as one big chunk). An committed_heap input parameter (in
   kB) is used to try to match a piece of memory that matches the
   committed_heap as best as possible.
 - No swap space is used (only resident memory is counted).

And a lot of reverse engineering-style educated guessing is going on
here!

Tested with Oracle JRE 6 and 7 on Linux 2.6.32, 3.2 and 3.16 so far...

This module is not integrated yet with the munin plugin. It can be
tested in a 'stand-alone' way by executing it and providing a pid and a
amount of kB for jvm committed heap memory that can be retrieved by
running statistics at the m2ee prompt.

E.g. python smaps.py 21429 251904