Memory management is central to every program. Dangling pointers due to improper memory management procedures are among the banes of C and C++. Automatic free memory management, or garbage collection, is inherent to platforms like Java and Microsoft’s .NET. In the latter, “managed” applications like those written in C# utilize garbage collection.
Around for ages, garbage collection was used early on by Lisp. Java and .NET are the current mainstream solutions that employ it. Garbage collection doesn’t completely eliminate memory-related programming errors, but it does remove many issues like uninitialized or dangling pointers.
Garbage Myths And Facts
Java and C# programmers tend to take garbage collection as fact, but many others look at it with disdain usually because they misunderstand the technology. For example, many programmers wouldn’t consider using garbage collection in real-time applications because of the pause it requires. This is true for stop-mark-sweep garbage collectors (see the figure). These days, most systems employ concurrent, generational garbage collectors that suit interactive and real-time environments.
Likewise, there is an assumption that garbage collection has significant overhead and skilled programmers can always do better using explicit allocation. There were similar arguments comparing assembly language to high-level languages, but it’s now hard to find a programmer who even knows what assembly language is. This is true even for embedded programmers. The truth is that garbage collection provides better performance in general than explicit memory management.
Looking under the hood of a garbage collection system is a major effort, which is why these systems tend to be black boxes for most programmers. There are many variations, such as stop-the-world, incremental, and concurrent collection methodologies. There are also variations such as in-place, copy, and compacting garbage collection.
The interesting aspect of these considerations is that they affect performance and overhead but usually do not affect the languages that utilize garbage collection. Garbage collection technology has also moved past simple allocate/dereference protocols. Java and .Net support dispose and finalize semantics, enabling programmers to provide class methods for objects to handle how an object goes away.
A program can call dispose while the garbage collector calls finalize. Dispose provides a shutdown mechanism, while finalize is called just before the object is returned to free space. These methods can be used to release resources that may not be managed by the memory system. For example, a finalization method might release a window handle or communication connection.
Embedded, Real-time Garbage
Atego’s aonixPerc and Oracle’s Sun Real Time Java are two Java implementations that provide real-time garbage collection. Microsoft’s .NET also provides a selection of garbage collectors for developers to employ.
Azul Systems targets the enterprise with its Java solution, which uses its Pauseless Garbage Collection. The company also is sponsoring the open-source Managed Runtime Initiative, which addresses garbage collection as just one of its issues.
Efficient garbage collection can take advantage of features such as virtual memory support that might otherwise be unavailable to applications. Having access to these facilities in a controlled fashion would allow platforms like Azul’s Zing to run on a range of operating systems.
Managed environments like Java and .Net are becoming more desirable for embedded applications if you know what to look for—or, in the case of garbage collection, letting the system look for it.