What are the reasons for why a Java/Linux stack fails to be "real time"?

Question

I have often heard developers mention that Java can't "do Real Time", meaning a Java app running on Linux cannot meet the requirements of a deterministic real-time system, such as something running on RIOT-OS, etc.

I am trying to understand why. My SWAG tells me that this is probably largely due to Java's Garbage Collector, which can run at any time and totally pause the system. And although there are so-called "pauseless GCs" out there, I don't necessarily believe their advertising, and also don't have $80K-per-JVM-instance to fork over for a hobby project!

I was also reading this article about running drone software on Linux. In that article, the author describes a scenario where Linux almost caused his drone to crash into his car:

I learnt a hard lesson after choosing to do the low level control loop (PIDs) on the Pi - trying to be clever I decided to put a log write in the middle of the loop for debugging - the quad initially flied fine but then Linux decided to take 2seconds to write one log entry and the quad almost crashed into my car!

Now although that author wrote his drone software in C++, I would imagine a Java app running on Linux could very well suffer the same fate.

According to Wikipedia:

A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed.

So to me, this means "You don't have real-time if total correctness requires logical correctness and timeliness."

Let's pretend I've written a Java app to be super performant, and that I've "squeezed the lemon" so to speak, and it couldn't reasonably be written (in Java) to be any faster.

All in all, my question is: I'm looking for someone to explain to me all/most of the reasons for why a Java app running n Linux would fail to be a "real time app". Meaning, what are all the categories of things on a Java/Linux stack that prevent it from "being timely", and therefore, from being "totally correct"? As mentioned, it looks like GC and Linux log-flushing can pause execution, but I'm sure there are more things outside the Java app itself that would cause bad timing/performance, and cause it to meet hard deadline constraints. What are they?

Answer 1

A software is real time not when it is as fast as possible, but when it is guaranteed that a process completes within some determined time slot. In a soft real time system, it is good but not absolutely necessary that this is guaranteed. E.g. in a game, the calculations necessary for a frame should complete within the period of a frame, or the framerate will drop. This degrades the quality of the gameplay, but does not make it incorrect. E.g. Minecraft is enjoyable even though the game occasionally stutters.

In a hard real time system, we don't have such liberties. A flight control software must react within some deadline, or the vehicle could crash. And the hardware, OS, and software must work together to support real time.

For example, the OS has a scheduler to decide when which thread is run. For a real-time program, the scheduler has to guarantee big enough, frequent enough time slots. Any other process that wants to execute in such a slot must be interrupted in favour of the real-time process. This requires a scheduler with explicit real-time support.

Also, a user-space program will do system calls into the kernel. In a real-time OS, these too must be real-time. E.g. writing to a file handle would have to be guaranteed to take no more that x time units, which would solve the log problem. This impacts how such a system call can be implemented, e.g. how buffers can be used. It also means that a call must fail if it can't complete within the required time, and that the user-space program must be prepared to deal with these cases. In the case of Java, the JVM and the standard library are also kernel-like and would need explicit real-time support.

For anything that is real-time, your programming style will change. If you don't have endless time, you have to restrict yourself to small problems. All your loops must be bounded by some constant. All memory can be allocated statically, since you have an upper bound on size. Unrestricted recursion is forbidden. This goes against a lot of best practices, but they don't apply for real-time systems. E.g. a logging system might use a statically allocated ring buffer to store log messages when they are written. Once the start is reached, old logs would be discarded, or this condition might be an error.

Answer 2

From wikipedia:

A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task; the variability is jitter.

The important thing is that jitter is quantified for the system to be considered real time. The article goes on to say that if the jitter is usually bounded, the system is soft real-time. If the jitter is always bounded, the system is hard real-time.

Unless the versions of Java and Linux you use are quantified in terms of jitter, they're not real-time. Garbage collection and log-writing are certainly sources of jitter, but even autonomous processing of (e.g.) network packets counts if it introduces jitter into your processes.

Answer 3

For starter, the vanilla Linux itself can't do real time. That's why RTLinux was developed.

Lets say you run a few java processes on RTLinux, they would still be considered real time as all those processes are scheduled by the kernel, i.e. if one process is late, other processes still can have their slice of cpu time, guaranteed.

Now, if the java processes run Green threads, then the execution of these threads won't be real time anymore since the JVM doesn't do real time scheduling.