Space overhead doesn't matter for most applications. But it makes Java a no-go for embedded devices and data-intensive domains.
Another disadvantage of using a Garbage collector, is that it's hard to predict when the JVM will "freeze" to collect garbage memory. This makes standard Java relatively ill-suited for real-time applications. For these, you need to consider technologies such as http://en.wikipedia.org/wiki/Real_time_Java
The problem with those GC freezes, is that they can be quite long in big memory-intensive applications. This is a reason for the work on alternative parallel GCs. The complexity and relative mysteriousness of the GC makes it hard to tune. Dhanji, a Google Wave engineer, who wrote the "Dependency Injection" book, and is the lead developer of sitebricks, wrote a great article on this subject : http://dhanji.posterous.com/taking-out-the-trash-and-other-c...
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)
"We present a novel experimental methodology that lets us treat unaltered Java programs as if they used explicit memory management. Our system generates exact object reachability information by processing heap traces with the Merlin algorithm [34, 35]. It then re-executes the program, invoking free on objects just before they become unreachable. Since this point is the latest that a programmer could explicitly free objects, our approach conservatively approximates explicit memory management."
Finally, according to the following (2005) article by Brian Goetz, using a garbage collector may yield more opportunities for optimization, at the cost of predictability: http://www.ibm.com/developerworks/java/library/j-jtp09275/in...
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.
