4 ms·

This is known, but it's always possible to overcome these situations and its part of the language maturing. Golang has already had its run with optimizing their

This is known, but it's always possible to overcome these situations and its part of the language maturing. Golang has already had its run with optimizing their GC for real-time systems. Twitch uses Golang for their IRC chat, and they've taken the Golang GC on a journey which you can read about here: https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7#.llxuytl1s https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06... Crystal will at some point also be forced to optimize their GC for these cases, although it currently uses an out-of-the-box GC called Boehm-Demers-Weiser conservative garbage collector http://www.hboehm.info/gc/ http://www.hboehm.info/gc/ which they have acknowledged they need to replace sooner or later.

pcr0 10y ago
The parent comment is referring to hard real-time systems (where not responding within a certain timeframe would lead to catastrophy). We're talking things like pacemakers, anti-lock brakes, industrial control systems. Regardless of how good GC is you would never use it in a hard real-time system because it is non-deterministic. IRC chat is only soft real-time.
- Svenskunganka 10y ago
  Ah, I see what you mean. Thank you for clarifying!
- adrianN 10y ago
  Those kinds of systems won't get compilers for something other than C/C++ or maybe Ada for a long time. Usually you're stuck with a compiler from the chip vendor that kinda-sorta supports C.
  - lomnakkus 10y ago
    Indeed, and you'll probably also need a special-purpose RT OS stack (or have to write your own/go without). EDIT: I'd also add that this is such a niche[1] area of programming that expecting any mainstream language to meaningfully support it is... optimisitic and that mainstream languages shouldn't try to support it. (Soft real-time may be reasonable, but I believe that can be achieved with GC as demonstrated by the Azul JVM.) [1] Niche, but obviously important, but perhaps not lucrative enough for anything to displace C or perhaps Ada -- given that these industries tend to be extremely conservative. (I wonder if ATS is used, though. Can't claim it's pretty, but proof seems like it would be a good thing for these systems?)
    - pjmlp 10y ago
      Special versions of Java also get into this niche. Check the PTC Java compilers or Websphere Real Time one from IBM. Before Aonix got bought by PTC they had a few contracts for weapons control for missiles and battle cruisers.
- rm445 10y ago
  Just as a point of interest, I believe there are special forms of garbage collector that are suitable for hard real time systems. The principle is to regularly use a bounded amount of time for collecting - in line with the latency requirements for the whole system. I think the relevant term is 'tick tock', as in tick - compute, tock - collect.
  - friendzis 10y ago
    The thing about hard real time systems is that they must be predictable, which is quite wide term. Predictable memory utilization, predictable computation cost, predictable response time. In an attempt to at least fit into these requirements GC must be "passive", on-demand i.e. callable from code. Even with bounded collect times, number of collectings must be predictable/controlled to predict computational cost/time of code paths. And that becomes not much different from manual memory management.
    - chaoxu 10y ago
      If there is no need for predicting memory utilization, then doesn't real time GC fit the bill? Consider all your know w/e you want execute in time T. A real time GC make sure it always execute in time 2T. For any sequence of operations.
    - _pmf_ 10y ago
      > Predictable memory utilization, predictable computation cost, predictable response time. All of these can happen with non-GCd languages through heap fragmentation (i.e. even when correctly allocating and deallocating memory, you can still end up with a fragmented heap.) Tho only way to aviod this is to avoid all dynamic allocation (which is indeed done in a lot of systems) or exclusively use memory pools instead of a traditional heap.
- imtringued 10y ago
  In those situations you wouldn't even use malloc and simply allocate everything statically.

pcr0 10y ago

The parent comment is referring to hard real-time systems (where not responding within a certain timeframe would lead to catastrophy). We're talking things like pacemakers, anti-lock brakes, industrial control systems. Regardless of how good GC is you would never use it in a hard real-time system because it is non-deterministic. IRC chat is only soft real-time.

Svenskunganka 10y ago
Ah, I see what you mean. Thank you for clarifying!
adrianN 10y ago
Those kinds of systems won't get compilers for something other than C/C++ or maybe Ada for a long time. Usually you're stuck with a compiler from the chip vendor that kinda-sorta supports C.
- lomnakkus 10y ago
  Indeed, and you'll probably also need a special-purpose RT OS stack (or have to write your own/go without). EDIT: I'd also add that this is such a niche[1] area of programming that expecting any mainstream language to meaningfully support it is... optimisitic and that mainstream languages shouldn't try to support it. (Soft real-time may be reasonable, but I believe that can be achieved with GC as demonstrated by the Azul JVM.) [1] Niche, but obviously important, but perhaps not lucrative enough for anything to displace C or perhaps Ada -- given that these industries tend to be extremely conservative. (I wonder if ATS is used, though. Can't claim it's pretty, but proof seems like it would be a good thing for these systems?)
  - pjmlp 10y ago
    Special versions of Java also get into this niche. Check the PTC Java compilers or Websphere Real Time one from IBM. Before Aonix got bought by PTC they had a few contracts for weapons control for missiles and battle cruisers.
rm445 10y ago
Just as a point of interest, I believe there are special forms of garbage collector that are suitable for hard real time systems. The principle is to regularly use a bounded amount of time for collecting - in line with the latency requirements for the whole system. I think the relevant term is 'tick tock', as in tick - compute, tock - collect.
- friendzis 10y ago
  The thing about hard real time systems is that they must be predictable, which is quite wide term. Predictable memory utilization, predictable computation cost, predictable response time. In an attempt to at least fit into these requirements GC must be "passive", on-demand i.e. callable from code. Even with bounded collect times, number of collectings must be predictable/controlled to predict computational cost/time of code paths. And that becomes not much different from manual memory management.
  - chaoxu 10y ago
    If there is no need for predicting memory utilization, then doesn't real time GC fit the bill? Consider all your know w/e you want execute in time T. A real time GC make sure it always execute in time 2T. For any sequence of operations.
  - _pmf_ 10y ago
    > Predictable memory utilization, predictable computation cost, predictable response time. All of these can happen with non-GCd languages through heap fragmentation (i.e. even when correctly allocating and deallocating memory, you can still end up with a fragmented heap.) Tho only way to aviod this is to avoid all dynamic allocation (which is indeed done in a lot of systems) or exclusively use memory pools instead of a traditional heap.
imtringued 10y ago
In those situations you wouldn't even use malloc and simply allocate everything statically.