Memory Access Isolation

From a visualization standpoint, it might be interesting to be able to show with what degrees of code-level isolation different regions of memory are accessed. For example, being able to show what areas of code touch individual heap allocations could provide interesting insight into the containment model of an application that is being analyzed. This type of analysis might be able to show how well designed the application is by inferring code quality based on the average number of areas of code that make direct reference to unique heap allocations. Since this concept is a bit abstract, it might make sense to discuss a more concrete example.

One example might involve an object-oriented C++ application that contains multiple classes such as Circle, Shape, Triangle, and so on. In the first design, the application allows classes to directly access the attributes of instances. In the second design, the application forces classes to reference attributes through public getters and setters. Using memory access behavior to identify code-level isolation, the first design might be seen as a poor design due to the fact that there will be many code locations where unique heap allocations (class instances) have the contents of their memory accessed directly. The second design, on the other hand, might be seen as a more robust design due to the fact that the unique heap allocations would be accessed by fewer places (the getters and setters).

It may actually be the case that there's no way to draw a meaningful conclusion by analyzing code-level isolation of memory accesses. One specific case that was raised to the author involved how the use of inlining or aggressive compiler optimizations might incorrectly indicate a poor design. Even though this is likely true, there may be some knowledge that can be obtained by researching this further. The author is not presently aware of an implementation of this concept but would love to be made aware if one exists.