add fragmentation analysis feature

_From [derek.br...@gmail.com](https://code.google.com/u/117968039472581148324/) on December 10, 2010 19:52:20_

PR 557071

another user feature request is to provide a memory map in some form for fragmentation analysis

what form it would take is TBD: just dump all addresses? compress it somehow to coarser granularity?
does user want raw data to run own analysis, or user wants visualization via the existing GUI framework?

There are two parts to this. First is, as you say, to dump all addresses of live mallocs at snapshot point. Second is to group them into some sort of map and display them with the ability to zoom in (because we can't possibly display 4 GB of address space within a 7"x5" window. I have spent some time thinking about this. The idea I like so far is to have a 16x16 grid and using it display 4 GB address space. Each grid will display a color depending upon its use, say white if 0%, yellow if less than 25%, orange for 50%, red for 75% and maroon for 100%. When each grid block is selected, we zoom into that 16 MB grid (4 GB is 2^32 and 16x16 grid shows 2^8, so each grid block is 2^24, i.e., 16 MB). We could go down to 3 levels, 4 is theoretical max (not sure if byte level display is needed). At the final level, we can display the associated callstack. I haven't quite worked out how expensive it will be to calculate such grids on the fly.

Based on the quick informal poll I had at the UW team, the idea of using a 2 dimensional grid to display memory fragmentation, i.e., usage doesn't seem to jive well with engineers. They prefer a linear display, something similar to Windows XP's defragmentation utility.

Design choice: When showing a strip to visualize the whole memory (4 GB, we do 32-bit apps only), there are two options for viewing memory regions in detail, i.e., zooming (can't use a slider as there are 4 billion+ points of choice). We start with displaying 16 MB chunks (256 vertical lines with 2 pixels/line it is 512 pixels which is more than half the width of our visualization tool's display - 1 pixel is too hard for folks to see, besides 16 MB vs 8 MB chunks don't make that much of a difference).
1. If the user clicks on a point in the strip, just zoom into that 16 MB and make the whole strip show that 16 MB, if the user clicks again, zoom into the 64k chunk. Another click, zoom into the last 256 bytes. This limits the user in the size and boundaries of the region they can zoom into, but will probably be simpler to implement.
2. If the user left-clicks, use that spot as the new lower end of the strip. If the user right-clicks, use that spot as the new high end of the strip, so the user can zoom in at any random granularity. This is more elegant I think, but sort of harder to implement.

In both cases we need to display what region is being displayed and a way to zoom back to seeing the whole memory region.

Derek felt `#1` was good enough. For the first step I agree too, esp. because I have no idea of how to do this GUI.

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=228_