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 (brian@quiotix.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.

Model Driven Architecture: Emergence of a BOA

At the OMG Healthcare Day in Orlando on 24 June 2004, we were relaunching the OMB Healthcare Domain Task Force and discussing incorporation of HL7 healthcare models into the OMG Model Driven Architecture.

I had a major case of "deja vue all over again" as I reminded the group how we launched the OMG Business Object Domain Task Force (BODTF) almost a decade ago. A similar strategy seemed appropriate for the Healthcare Domain Task Force.

The core strategy of the BODTF was implementing the ANSI X3H7 Object Management Technical Committee Standardization Targets of 24 Sep 1994 (see graphic above). Serendipitously, I had the experience today of finding a published paper of mine in the IEEE Computer Digital Library that I did not know was ever published. This had the 1994 graphic above which is almost the same graphic used in Paul Harmon's recent article on the OMG MDA in Business Process Trends.

This paper was ultimately published in ACM StandardView. You can check out the original using the link below:

Sutherland, J. (1999). The Emergence of a Business Object Architecture. IEEE 8th International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, Palo Alto, IEEE.