hmm, zajimavej komentar k tematu ze Slashdotu:

When you're doing serious structure-hackery (as opposed to, say, string-hackery or numeric-hackery) in a non-GC language, you often end up having to structure your code around variable lifetimes, rather than structuring it around the algorithms like you're supposed to. The lack of GC can mean that some algorithms are not viable, and can result in the developer picking a worse algorithm instead. This kind of cost won't easily show up on a profile, but the cost is there, and it's nonzero.

Compiler writers in particular know this, which is why even GCC uses GC. Yes, it's home-built application-specific carefully-applied-and-tuned GC, but it's GC nonetheless. I have a theory that one of the reasons why most languages use GC is that most languages are optimised for writing their own compiler in.

Oh, and in a multi-threaded application, free() can be more expensive (in a latency sense) than malloc(). A well-tuned memory allocator maintains multiple arenas, so it can can allocate memory from whichever one has the lowest thread contention. But deallocating memory requires returning it to the arena from whence it came; you have no choice in this. Some high-performance applications (e.g. database servers) have been known to avoid the latency of free() by handing off critical memory blocks to a dedicated thread which just sits in a loop calling free(). Essentially, it's a GC thread, only it's a manual one.

Don't get me wrong. I don't use Java for pretty much anything (definitely more of a C++-head). But one should never underestimate the cost of manual memory management, or of any other resource for that matter.

XCHAOS: Mě se líbí tento titulek
Google pits C++ against Java, Scala, and Go: C++ wins. If you're a genius
Google pits C++ against Java, Scala, and Go • The Register
http://www.theregister.co.uk/2011/06/03/google_paper_on_cplusplus_java_scala_go/