4 ms·

Hard real time GC is hard. The RTGC applications in military tech that I had heard of were on the soft end of hard real time. It was mission critical, not safe

• lisper 4y ago
  > Hard real time GC is hard. Hard real time is hard, full stop. If you have malloc and free you will encounter the exact same real-time challenges as you will with GC. Heck, you don't even need malloc and free. All you need is a WHILE loop to make hard-real-time extremely challenging.
  • pizlonator 4y ago
    GC makes hard real time harder. Way worse than malloc. GC usually works by amortization. 99.99% of allocations are hella fast and then there’s that one that triggers a one second GC that stops the world. There are algorithms to “spread out” the GC cycle over some span of time during which you interleave the GC and your actual code. But then proving that this is schedulable in the worst case is hell. So much hell. I get that real time is hard anyway already. GC just makes it worse.
    • lisper 4y ago
      Malloc has the exact same structure: it's hella fast until you run out of RAM and it returns an allocation failure. The only difference between the two is that with GC you expect to run out of RAM and you expect the system to not just go down in screaming flames when that happens. And yes, that is harder to arrange. But it's not because there is anything inherently harder about GC. The only difference is the expectations about what will happen in the long run, and how much work the programmer has to do to prevent running into the worst-case scenario.
      • KerrAvon 4y ago
        I can’t make any sense out of your equivalency assertion. GC won’t magically reclaim memory that is still referenced; there still comes a point where if you can’t demand-page new memory in, you’re going to fail. Are you assuming the malloc-based system hasn’t been debugged and has severe memory leaks? Are you assuming a compacting collector will allow space to be reclaimed that free() wouldn’t.
        • lisper 4y ago
          > GC won’t magically reclaim memory that is still referenced I never said it would. What I said that making GC hard-real-time is no more difficult than making malloc/free hard-real-time. You can do manual memory management in a GC'd system. If you do that, the two systems are literally the same. The only difference between GC and manual memory management is that in a GC'd system, unreferenced memory will eventually be reclaimed and in a manual system it won't. If you lose all references to an allocated block in a manual system, it's gone forever, whereas in a GC'd system you can get it back. This enables a programming style that puts less burden on the coder to prevent memory leaks. But none of this has anything to do with being hard-real-time. Hard-real-time is hard, period, end of story. GC is completely orthogonal to this. Hard-real-time is hard in a GC'd system and it is exactly as hard in a non-GC'd system. The only difference between the two is the same in both hard-real-time and non-hard-real-time cases: in a non-GC'd system, the coder has an extra burden to write code that doesn't leak. That's it.
      • silon42 4y ago
        In a real time system you probably shouldn't run out of RAM (or it should be a recoverable error, like dropping a packet). But GC pause is inevitable if the GC can't reliably keep up (like a spike in workload).
        • lisper 4y ago
          > GC pause is inevitable No, it isn't. That's the magic of hard-real-time GC. It isn't easy, but it is possible. [EDIT: A more accurate claim is that GC pause is no more inevitable than an allocation failure in a malloc/free system.]
  • agumonkey 4y ago
    I wonder if people in RT domains just skip imperative programming to go into reactive (a la lucid/lustre/esterel) signals.