Region Based Memory Management

Aside from listening and witnessing some of the most righteous of music (I'm listening to Gogol Bordello right now), and caught some Iron Maiden, Primus, and Slayer at Soundwave last week, what have I been researching, is a question one might be asking themselves. Ok yeah that is one nasty grammatically incorrect piece of English. Well what have I been researching?

Region Based Memory Management! That's right, that is what my PhD is focused on. Sure RBMM is not fresh, but my goal is to implement it for Google's Go language. What I think will be the real unique pieces of research will be how we allocate our regions, dealing with parallization (a'la goroutines) and carrying information across multiple modules (cross-module analysis).

Backup just one second cowboy, neee hawwww! What in the name of doo dah is a region? Region based memory management is a way of managing memory at compile time, one might think of it as compile-time garabage collection. However, that is just not correct at all. At compile-time, via static analysis, dynamic memory allocation calls are located. The compiler can then emit code that will allocate objects that have the same lifetime into regions of contiguous memory. So its a neat little tango between compile-time and run-time communication. Anyways, this grouping of objects with similar lifetimes can benefit cache locality, as well as provide a fast way of deallocating objects, all at once, by just killing the region. That is fast. No need to visit each object individually and free it.

Since Go utilizes a garbage collector, we would like to leave it in place for dealing with cases where regions would live for a long, if not infinite time. Such a case would be when a global object aliases something that is dynamically allocated (in Go that would be via a call to 'new' or 'make'). Garbage collection is traditionally a "slow" process. In addition, collectors can be a burden to real-time systems, as they can slow the program's execution (or even stop it) allowing the collector time to clean-up objects that are no longer being used. Of course, there are parallel garbage collectors, which should not require a stop-the-world approach that traditional collectors implement. But, I am unaware of their actual processing capabilities/limitations.

TL;DR my thesis at this time poses to provide an elusive seductive dance between garbage collection and region based memory management. OhhhhHhh yeaaa mmmmmm mm that sounds like the sexxy.

-Matt