You can download the paper from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.9682&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download

You can download the paper from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.9682&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.... All this being said, I don't know if it's fair to compare the approach mentioned in your link with "classical" manual memory management. How often do you see this kind of (de-)allocation patterns in a standard app? Wouldn't a programmer often write "less than ideal" de-allocation code? (honest question there, I sadly never had the opportunity to write in a language with manual memory-management) You're on the right track, but with a twist: Explicit memory management works the opposite way around. Freeing an object when it goes out of scope, like the paper's oracle, is the worst case scenario. A real programmer is free to optimize and release memory before that, even if the object still has references. In practice, I doubt the difference matters. The primary focus of memory management in C/C++ is avoiding leaks from objects that were never freed and can never be freed because all their references are out-of-scope. Programmers have a small window to free memory, before the pointers are out of scope, but only once the object isn't needed. There's not much room for optimization.