Oso Memory Profiler - Overview

The Oso Memory Profiler
Memory profiling for the 21st century.

Memory Graphs

Memory graphs.
Memory graphs

The top segment of the Oso Memory Profiler contains the memory graphs.

There are two primary types of graph:
  1. Memory Graph
    This graph shows you how much memory is being used by your application at any given time.

  2. Change Graph
    The change graph shows how much memory your application has allocated and freed for any given point in time. This type of graph makes it very easy to spot spikes in your application's memory usage patterns.

Each of the graphs breaks down memory usage by block type, to further make it easier to distinguish different parts of your application.

In addition to the two main types of graph, you can also modify the horizontal axis to represent either time or memory events. The former obviously showing you how memory was consumed during the lifetime of your application, while the latter gives you a better navigation space by compressing long periods of inactivity.

The graphs can and should be used as an initial navigation tool into the event streams. The shader area will show you which part of the profile is currently being displayed in the event streams. Or, in the case of the memory map view, which moment in time is being studied.

Threaded event streams

Event streams.
Threaded event streams

The event streams in the main pane of the Oso Memory Profiler's window show all events (as defined by any current filters) ordered by time (along the horizontal axis) and split into streams, where each stream represents a single thread of execution within the application being profiled.

Events rising up from the middle of the stream are allocation events, while events falling down from the middle are free events, where the length of the event bar gives an indication of the size of the memory block being allocated or freed. The colour of each bar is defined by the type of memory block being allocated or freed.

Message events occupy the entire vertical space within a stream, and are coloured directly by the application when generating the message event during profiling.

Finally, significant gaps in time where no events occur are marked as bars over the entire vertical space of the view. The length of the gap is shown at the top of the view.

Events will usually have clear backgrounds (I.e., the colour of the stream will be visible behind them), but any events with errors or warnings associated with them will have red or yellow backgrounds respectively.

You can click on any event to view detailed information.

Memory maps

Memory maps.
Memory maps

The Oso Memory Profiler's memory map shows you where in memory your currently allocated blocks are located. By choosing a point in time from the top graphs, you can see an overview of how your application's memory is laid out at that moment.

The memory map is split into two halves:
  1. The top half shows a higher level view of 64KB memory pages. Each page in this section shows you how much memory in any given page is actually allocated (the height of the coloured block), while the colour gives an indication of how fragmented memory is within that page.

  2. The bottom half shows individual bytes within the selected page. Allocated blocks are rendered using the colour defined by their type.

You can click on any allocated block to view detailed information.

Grouped memory blocks

Block lists.
Memory blocks

The Oso Memory Profiler's block list, groups all memory blocks in two different ways:

  1. By block type
    The Oso Memory Profiler supports two different block types by default:

    • Memory blocks
      Technically everything is a memory block, but in this instance, these are any block that doesn't have a user defined type.

    • Memory buckets
      A memory bucket is essentially a single memory block from which actual memory blocks can be allocated by a memory manager that provide pooled memory management.

    In addition to these standard types, however, an application can also register its own custom types. Typically you would use these types to distinguish how memory is being used. For example, you might want to be able to see memory which is used for images. Registering an image type through the Oso Memory Profiler's SDK would allow you to do this.

  2. By header
    The second level of grouping (essentially each row within the blocks view) is the block header. For standard block types the header is merely the size of the memory block in question, but custom block types are free to specify custom format strings that can use any registered attribute types to create a header string. In the above image type example, a block header might consist of the width and height of the image. In this case, the Oso Memory Profiler would group images of the same size together.

View callstacks

Callstack tree.
Callstacks
The Oso Memory Profiler's callstack tree combines all event callstacks into a single tree with each stack frame within the tree sorted according to how often it appears. It is therefore extremely easy to see which parts of your application are generating the most memory events.

Clicking on any frame in the tree will open a new filtered events view, so you can quickly view and assess any potential problems.
 

Threads Overview

Threads overview
Threads
The threads pane gives a top level overview of how memory events are spread across all the threads in your application.

This pane also serves as a legend for the thread streams in the main part of the Oso Memory Profiler window.

Detailed event information

Event details.
Event details

Event callstack.
Event callstack

Event problems.
Event problems

Event attributes.
Event attributes
Clicking on any event or memory block in one of the other views displays detailed information about that event.

Detailed information is split into four distinct parts:
  1. Header
    The header section at the top shows at a glance what was allocated, where it was allocated (which thread at least), and when.

  2. Callstack
    Each event related to a memory block will have at least one callstack - for when the memory block was allocated. As long as the memory was freed later, there will also be a second callstack for that free event.

    Messages will have a single callstack for when the message was generated.

  3. Problems
    Any problems which have been identified will also be listed with as much information as possible to help identify exactly what caused the problem to be identified in the first place.

  4. Attributes
    Finally, all known attributes about an event will also be listed. These will include application defined attributes as well as standard event information presented in attribute form for completeness.

Easily locate problems

There are several different types of problem that the Oso Memory Profiler can detect automatically. In addition to these you are free to define your own error and warning expressions that the Oso Memory Profiler will evaluate while a profile is loading.

The standard problems that the Oso Memory Profiler will detect are detailed below:

Memory leaks
Memory leaks are essentially memory blocks that have been allocated, but never freed. A leaky 32-bit application will eventually run out of memory and crash. A leaky 64-bit application could potentially fill up the swap space on your hard drive and cause problems for other applications.

Freeing memory twice
A much rarer error is freeing a block of memory more than once. While not a huge problem in itself, this type of error could indicate a much larger, and often hidden problem: Writing to a memory block after it has been freed.

Temporary allocations
Allocating and freeing memory is a slow task. Having lots of temporary allocations will drag the performance of your application down. Quite often temporary allocations come from the most unexpected places too.

Cross-thread freeing
In today's multithreaded world, allocating in one thread and freeing in another is almost unavoidable. Sometimes it's even actively enforced. So while we don't generally view this as being a particularly important issue, it can have some performance implications, so the Oso Memory Profiler can highlight these if you require.