Helping the Garbage Collector ... NOT!
Some years ago, I posted a note on the importance of garbage collection and the fact that introducing a C++ garbage collector would make most C++ applications run faster, reduce lines of code, lower the number of bugs, and simplify design.
This is not a hallucination. It remains a fact today. I spent a lot of time digging into this when I was VP of Object Technology at a Smalltalk company. I directed the migration of a mark-sweep garbage collector in our Smalltalk compiler to a generational collector.
All garbage collectors are not equal. In Java 1.0 and 1.1, a mark-sweep collector was used that could result in penalties for allocation and deallocation. There are a lot of Java articles out there that still recommend things like object pooling as a result.
In Java 1.2, a generational collector was introduced. This improved performance to the point where most developers should not even think about garbage collection. Almost anything they do will increase design complexity, increase lines of code, increase bugs, and decrease performance.
Java theory and practice: Garbage collection and performance
Hints, tips, and myths about writing garbage collection-friendly classes
Brian Goetz (email@example.com)
Principal Consultant, Quiotix Corp
27 Jan 2004
The past two installments of Java theory and practice have discussed various techniques for garbage collection and the basics of the JDK 1.4.1 garbage collectors. This month, columnist Brian Goetz looks at the performance impact of the choice of collector, how various coding idioms interact with the garbage collector, and how allocation and other related costs have changed in Java virtual machines over the past several years. Share your thoughts on this article with the author and other readers in the accompanying discussion forum. (You can also click Discuss at the top or bottom of the article to access the forum.)
In the early days of Java technology, allocating objects got a pretty bad rap. There were lots of articles (including some by this author) advising developers to avoid creating temporary objects unnecessarily because allocation (and the corresponding garbage-collection overhead) was expensive. While this used to be good advice (in situations where performance was significant), it is no longer generally applicable to all but the most performance-critical situations...
For most applications, explicit nulling, object pooling, and explicit garbage collection will harm the throughput of your application, not improve it -- not to mention the intrusiveness of these techniques on your program design. In certain situations, it may be acceptable to trade throughput for predictability -- such as real-time or embedded applications. But for many Java applications, including most server-side applications, you probably would rather have the throughput.