Java Real-Time Programming – Beyond Garbage Collection

This is an old idea, that has popped up an unbelievable number of times over the last several decades. LabView (I think that's the name) is the best-known current version.

I worked with one such system, called RIPPEN, from Orincon (as I recall), around 1998-1999. (Orincon was bought by Lockheed-Martin in 2003. The product appears to be dead and gone now.) The biggest drawback I noticed was that about 20% of my CPU time went to moving data around between processing blocks. Considering that I was doing significant numbercrunching (coordinate transformations, from az/el/range to X/Y/Z and then applying a coordinate system rotation: BUNCHES of trig and matrix/vector multiplication, 20% is a LOT of CPU time.

Around this time, I went to a function at my old university, and mentioned the product to an old friend, who was a grad student when I was there and is now a full professor. His answer was that he'd done a similar thing quite a number of years earlier.

Some advantages of reference counting over garbage collection:

1. Low overhead. Garbage collectors can be quite intrusive (e.g. making your program freeze up at unpredictable times while a garbage collection cycle processes) and quite memory-intensive (e.g. your process's memory footprint unnecessarily grows to many megabytes before garbage-collection finally kicks in)

2. More predictable behavior. With reference counting, you are guaranteed that your object will be freed the instant the last reference to it goes away. With garbage collection, on the other hand, your object will be freed "sometime", when the system gets around to it. For RAM this isn't usually a big problem on desktops or lightly loaded servers, but for other resources (e.g. file handles) you often need them be closed ASAP to avoid potential conflicts later on.

3. Simpler. Reference counting can be explained in a few minutes, and implemented in an hour or two. Garbage collectors, especially ones with decent performance, are extremely complex and not many people understand them.

4. Standard. C++ includes reference counting (via shared_ptr) and friends in the STL, which means that most C++ programmers are familiar with it and most C++ code will work with it. There isn't any standard C++ garbage collector, though, which means that you have to choose one and hope it works well for your use case -- and if it doesn't, it's your problem to fix, not the language's.

As for the alleged downsides of reference counting -- not detecting cycles is an issue, but one that I've never personally ran into in the last ten years of using reference counting. Most data structures are naturally acyclical, and if you do come across a situation where you need cyclical references (e.g. parent pointer in a tree node) you can just use a weak_ptr or a raw C pointer for the "backwards direction". As long as you are aware of the potential problem when you're designing your data structures, it's a non-issue.

As for performance, I've never had a problem with the performance of reference counting. I have had problems with the performance of garbage collection, in particular the random freeze-ups that GC can incur, to which the only solution ("don't allocate objects") might as well be rephrased as "don't use GC".