Hacker News new | ask | show | jobs
by gnzoidberg 1839 days ago
I don't think this is true. No current GC tech is fully hard real time. (I am happy to be corrected, as it'd make my life way easier)
2 comments

Those examples were naval ships. When you can float a huge data center in water and dump all the waste heat you want, it doesn't matter that the Perc vm used is 2.5x as slow as the sun vm. Or that it uses even more ram than a normal java vm which is already a lot. This is running on a microcontroller.
Moving goal posts?

I thought we were talking about real time GC, besides only the first example is a naval ship.

Both fair points. Hard real-time is absolutely doable with GC if it is deterministic. It has throughput and memory penalties to get low and predictable latencies but it is regularly done. I have written soft real time java myself. And other than avoiding garbage like you would do with any low latency code with GC, it was idiomatic. But that one change does increase cognitive burden to the point I didnt find it any more productive than C++. If I had needed reflection I might have felt differently.
> It has throughput and memory penalties to get low and predictable latencies

Hard realtime C++ does as well.

I've done lots of hard real time c++. It certainly has development time overhead, but the memory usage was the same as idiomatic c++, just everything was preallocated at max usage. No throughput hit either, if anything it was faster because of no allocations.
How does any of that matter? The parent comment provided examples of GC being used in hard real-time when the claim was that it couldn't be done.
Not hard real time, but with a fixed, short bound:

https://researcher.watson.ibm.com/researcher/view_page.php?i...

That's the definition of hard real time, if I'm not mistaken. Is there an even stricter guarantee than than that?
True, above that would be "live".