Why are garbage collection and automatic memory allocation considered drawbacks in some contexts?

Question

We can find one example in the book The Way To Go, by Ivo Balbaert:

However Go is not suited for real-time software because of the garbage collection and automatic memory allocation.

What makes garbage collected and automatic memory allocation languages not suited for the task?

Answer 1

• Garbage collection can be a problem because garbage collectors take some time to run, and this happens at unpredictable moments. A bad thing in real-time software.

• Automatic memory allocation by itself isn't strictly a problem, but:

  • In Go and similar languages it is closely tied to garbage collection.
  • Many real-time systems want to control their memory allocation as tightly as timings. Some programs don't use dynamic allocation at all. Done right, this means you can write programs that provably never run out of memory.

Answer 2

Essentially, you can't control when the garbage collector will run or how long it will take. Of course, a runtime will be designed so that the GC holds up other work as little as possible. But 'as little as possible' isn't good enough for real-time - there need to be guarantees that things will happen in a certain amount of time.

(Memory allocation is another operation that could take 'too long', and there might be other 'housekeeping' tasks that have to be run periodically. But if memory allocation takes a long time, it's probably because the GC needs to be run first.)