[__red__]

I'm not sure I understand what you mean by "real-time safe GC algorithms", but pony is not a language that has being a "real time system" as a design goal.

This pony paper here describes the pony GC algorithms and compares their performance under various scenarios to other language GCs.

https://www.ponylang.io/media/papers/orca_gc_and_type_system...

The charts you want to look at are on pages 19-21.

It shows that ORCA (pony's GC) has extremely low jitter and is highly performant compared to the other industry leaders at the time of publication.

[RossBencina]

Real-time safe GC algorithms and data structures provide strong guarantees that any interruptions to the running program caused by GC activity will have a bounded duration, with strong guarantees on the upper bound of any pause. This is important in latency sensitive software and real-time software that needs to meet deadlines.

Examples include IBM's Metronome: https://www.researchgate.net/publication/220829995_The_Metro... and https://developer.ibm.com/articles/garbage-collection-tradeo...

Thanks for the ORCA link. I'll have to study it more closely but from Fig 17 it looks to have quite unpredictable jitter up to at least 20ms. Which is obviously fine for many things but not useful for other things (e.g. processing AVB streaming audio packets at line rate every 125 us).

EDIT: I originally also cited the following, however I am not sure these were the papers that I was thinking of: Baker's algorithm: https://dspace.mit.edu/bitstream/handle/1721.1/41976/AI_WP_1... also discussed here: "Baker's garbage collector performs garbage collection in real time-- the elementary object creation and access operations take time which is bounded by a constant, regardless of the size of the memory." https://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Real...

[__red__]

It's less than a third of the others which are compared.

As with all things, we should use the correct language / runtime for the domain problems it's designed to solve.

The pony runtime makes other decisions (such as non-preemptable schedulers) which would have more of an effect on your use-case methinks.

Thank you for the discussion and your interest!