C still is the top embedded development language, while C++ and Java are catching up. Are you worried that trying these object-oriented platforms will poison the water, cause object-code bloat, and slow execution to a crawl? If you believe these myths, you don't know what you're missing.
Designers often discount C++ because compilers are supposed to generate lots of code. They also avoid it because it permits the use of expensive features, like multiple inheritance. Of course, you don't have to use these features. Better yet, if you use Embedded C++, you won't be able to use them. But I digress. The real topic today is Java, which is better for embedded applications than many people know.
We can skip over the myth that Java execution is slow because it is interpreted. It's simply not true. JIT (just in time) and AOT (ahead of time) compilers are the norm for embedded Java. Instead, let's concentrate on garbage collection. Most programmers consider it a plus in producing safe, reliable code, even though it is expensive and unpredictable. As with most myths, there is a ring of truth to it, especially when immature versions of Java are considered. This is akin to the overhead arguments that were brought up about C++ in the past. Yet as with these arguments, the truth about the latest Java incarnations is much different from the myth.
Let's look at unpredictability, which occurs when Java must stop and perform a garbage-collection sweep when an object is allocated but there is no free space. The way around this problem is relatively simple. Run garbage collection in parallel with the application so garbage is recovered before it is needed. Allocations occur constantly.
"Myths and Realities: The Performance Impact of Garbage Collection" compares garbage-collection approaches. Presented at a recent ACM Sigmetrics conference, this paper by Blackburn, Cheng, and McKinley also compares garbage-collection performance to C-style malloc. The authors conclude that a good garbage collector can deliver better performance. This may be counterintuitive, but take a closer look.
Consider how malloc works. The initial allocation for malloc and a garbage collector is the same. A new block of memory is obtained from the start of free memory. Things change when data is returned. Malloc typically puts data back into a linked list of free blocks. The allocation of data now requires walking the list to find a block large enough for the next allocation. Java would maintain its usual allocation method. Of course, the cost of performing a garbage-collection sweep must be better than the combined malloc/free operations, but this turns out to be true in many cases. This isn't the final word in the argument, yet it shows that garbage collection is a lot more competitive than you think.
Look for Java in environments that are more demanding, from games to tanks.
