Tuesday, August 18, 2009

Garbage collector for C - not for embedded systems programming

A quick and dirty post while drinking a tall, non-fat latte in a coffee shop. A few months ago, my friend asked me whether C/C++ had garbage collector, since there is no native garbage collector in C and C++. My answer was no. Apparently my answer was wrong. There is a garbage collector for C and it is not just some crackpot code, it is in Hewlett-Packard site. Sweet. But do C or C++ need it? I have coded Java for fun as well as for food. From coding perspective garbage collector is very helpful, making your job easy. Garbage collector is done efficiently without your intervention, but still it uses up considerable CPU cycles. So there are times in which the garbage collector has become a performance nightmare. In those cases, we need to tune the garbage collector for efficiency which takes time that you saved in coding.

C and C++ are used widely in embedded system, because of the efficiency, reduced CPU cycles, and real time performance. Although some have demonstrated Java program reaching up to the speed of C program, you cannot expect that consistently in a wide range embedded systems programming. Garbage collection is a sensible sensitization that you require when the operating system takes care of the memory. But in embedded systems programming, you know how much memory you have and you know what to do to manage that. It's the same way the operating system itself manages the memory. So you have to be sensible enough in your programming task to allocate and remove memory and construct and destroy classes. Leaving it to the garbage collector will slow down your embedded system.

Garbage collection is a great idea. C or C++ can use it certainly while programming a general purpose processor that runs an operating system. But it is not for embedded systems.

1 comment:

  1. The decision on to use or not to use a garbagge collector really depends on the problem space and the experience of the programmers involved imho.

    If you are worried about consistent and predictable realtime execution, random GC cycles won't help. If you are working with embedded systems and want a tight bound on the maximum rss at any point, GC won't help either.

    If you are working on highly layered software developed by multiple people and the documentation alone is not good enough to assert things like object ownership, the performance cost of GC often beats the cost of mental bandwidth required by the people working on the system.

    On most problems I work on, I operate between no-frills-attached-plain-c-programming and syntatic-sugar-enabled-fancy-python-with-deep-knowledge-of-the-vm-internals. Its very rarely that I run into problems where the complexity and performance of C++ or Java are forced on me.