Re:Crystal: Fast as C, Slick as Ruby
by friendzis on Thursday August 04, 2016 @04:26AM
(#12224214)
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.
[ Parent
| on HN ]
> 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.
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.