logoalt Hacker News

wk_endyesterday at 7:29 PM1 replyview on HN

Well, you're guaranteed not to be interrupted by garbage collection, which is the point here. Segments of code that are provably free of garbage collection can satisfy hard timing constraints, but that doesn't mean that they just will. It's a paper about garbage collection; addressing all the other things that need to be done to ensure compliance with hard real-time requirements is clearly outside the scope of the work.

I'm speaking a little outside my wheelhouse here (experts, please jump in), but my understanding is that if you have actual hard real-time requirements, you very well might turn off interrupts, multithreading, etc. and work with uncontested access to CPU/memory resources during time-sensitive parts of your code, as needed.


Replies

gf000yesterday at 8:55 PM

But that's still "draw the rest of the owl" category of complexity, and you probably can't really get hard real time on an ordinary kernel.

At that point you might as well take a look at runtimes that have a GC and is hard real time, which exists for the JVM. So not sure if it's really that valuable to separate out GC, especially when there are many other functions that can run much longer than expected (e.g. think of stack unwinding).