Interesting read, thanks. The cynic in me thinks 'deterministic garbage collection' is trivial depending on how you define it.
1. Start off with an ordinary JVM with a non-concurrent, non-parallel GC. Doesn't matter if it's generational.
2. Take an extremely conservative estimate of the worst-case full-GC pause time, given the hardware (ideally with excessively powerful hardware)
3. Set up the system to invoke full-GC every frame
We've now defined a system that will cope with GC pauses just fine, but we haven't done any real engineering. Their offering clearly isn't that lazy, they've apparently written their own AOT compiler, but it's hard to gauge how technically impressive their GC is.
I can post other articles, unfortunately the anti-GC crowd (in general) seems to think GC == whatever I know of the JVM on my computer and is completely oblivious of the various kinds of options available out there.
Ironically it tends to be the same crowd that is unware that high performance C usually doesn't use libc malloc()/free(), and there are companies that used to make a business out of selling specialized heap management libraries.
I was just wondering what these guys specifically had done. The new GCs in HotSpot - ZGC and Shenandoah - are extremely impressive technologies. I wonder if the PERC Ultra virtual machine does anything similar, or if it's just a simple GC with a cautious approach to timing commitments, which seems more likely to me.
Books like "Hard Realtime Garbage Collection in Modern Object Oriented Programming Languages", from one of the Aicas' founders are quite interesting reads.
Many discuss drop frames and jitter, while forgetting that a couple of ms more can result in someone's death in industrial automation or getting the wrong guys dead in weapon control systems.
