allocator_1.png

While re-writing my ui-library, I wanted a simple string allocator that would be an upgrade from the fixed strings that I originally used. I imagined an allocator that would return variably sized chunks from a pre-allocated arena depending on the request. "Freed" memory would pop onto a linked list. I wasn't sure if this was going to be faster, use less memory, or even work at all. I figured if I could somehow visualize the allocator over time I would be able to answer some of those questions.

The example program has two windows - the "App" contains the UI that is using the arena, and the "Memory Visualizer" shows a table of the arena with each "cell" representing a chunk of the smallest possible size, and whether or not they are allocated (green) or free(red). The allocator provides chunks in multiples of a minimum chunk size, and if a allocated string needs more than one chunk, the cells are visually linked with a green dot. The visualizer updates in real time as strings are allocated and freed.

The UI allocated two strings per visible element, and frees them if they disappear. I created a simple calculator app that has tooltips to show the visualizer in action.

As soon as I got the visualizer up and running it proved its worth by highlighting several issues with my little allocator.

String Memory Viz.exe

Recent Activity

This is my first jam - I decided to try and visualize how the string allocator that I am trying to write works (or doesn't). I spent most of this weekend trying to fix the allocator after I successfully visualized some of it's many problems...so I'd say this was a success!