Home/ Questions/Q 1041407
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T15:20:55+00:00

When building a system which needs to respond very consistently and fast, is having

  • 0

When building a system which needs to respond very consistently and fast, is having a garbage collector a potential problem?

I remember horror stories from years ago where the typical example always was an action game where your character would stop for a few seconds in mid-jump, when the garbage collector would do its cleanup.

We are some years further, but I’m wondering if this is still an issue. I read about the new garbage collector in .Net 4, but it still seems a lot like a big black box, and you just have to trust everything will be fine.

If you have a system which always has to be quick to respond, is having a garbage collector too big of a problem and is it better to chose for a more hardcore, control it yourself language like c++? I would hate it that if it turns out to be a problem, that there is basically almost nothing you can do about it, other than waiting for a new version of the runtime or doing very weird things to try and influence the collector.

EDIT

thanks for all the great resources. However, it seems that most articles/custom gc’s/solutions pertain to the Java environment. Does .Net also have tuning capabilities or options for a custom GC?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    To be precise, garbage collectors are a problem for real-time systems. To be even more precise, it is possible to write real-time software in languages that have automatic memory management.

    More details can be found in the Real Time Specification for Java on one of the approaches for achieving real-time behavior using Java. The idea behind RTSJ is very simple – do not use a heap. RTSJ provides for new varieties of Runnable objects that ensure threads do not access heap memory of any kind. Threads can either access scoped memory (nothing unusual here; values are destroyed when the scope is closed) or immortal memory (that exists throughout the application lifetime). Variables in the immortal memory are written over, time and again with new values.

    Through the use of immortal memory, RTSJ ensures that threads do not access the heap, and more importantly, the system does not have a garbage collector that preempts execution of the program by the threads.

    More details are available in the paper “Project Golden Gate: Towards Real-Time Java in Space Missions” published by JPL and Sun.

    • 0