¿Cuáles son las razones por las cuales una pila Java / Linux no puede ser "en tiempo real"?

A menudo escuché a los desarrolladores mencionar que Java no puede " hacer tiempo real ", lo que significa que una aplicación Java que se ejecuta en Linux no puede cumplir con los requisitos de un sistema determinista en tiempo real, como algo que se ejecuta en RIOT-OS, etc.

Estoy tratando de entender por qué . Mi SWAG me dice que esto probablemente se deba en gran parte al recolector de basura de Java, que puede ejecutarse en cualquier momento y pausar totalmente el sistema. Y aunque existen los llamados "GCs sin pausa", ¡no necesariamente creo en su publicidad, y tampoco tengo $ 80K por instancia de JVM para gastar en un proyecto de pasatiempo!

También estaba leyendo este artículo sobre la ejecución de software de drones en Linux . En ese artículo, el autor describe un escenario en el que Linux casi hace que su dron se estrelle contra su automóvil:

Aprendí una dura lección después de elegir hacer el bucle de control de bajo nivel (PID) en el Pi; tratando de ser inteligente, decidí poner un registro de escritura en el medio del bucle para la depuración: el quad inicialmente voló bien, pero luego Linux decidió tomar 2 segundos para escribir una entrada de registro y el quad casi se estrelló contra mi auto.

Ahora, aunque ese autor escribió su software de drones en C ++, me imagino que una aplicación Java que se ejecute en Linux podría sufrir el mismo destino.

De acuerdo con Wikipedia:

Se dice que un sistema es en tiempo real si la corrección total de una operación depende no solo de su corrección lógica, sino también del tiempo en que se realiza.

Entonces, para mí, esto significa " No tienes tiempo real si la corrección total requiere corrección lógica y puntualidad " .

Supongamos que he escrito una aplicación Java para que tenga un rendimiento excelente, y que he "exprimido el limón", por así decirlo, y que no podría escribirse razonablemente (en Java) para que sea más rápido.

En general, mi pregunta es: estoy buscando a alguien que me explique todas / la mayoría de las razones por las cuales una aplicación Java que ejecuta n Linux no podría ser una "aplicación en tiempo real". Es decir, ¿cuáles son todas las categorías de cosas en una pila Java / Linux que evitan que sea "puntual" y, por lo tanto, que sea " totalmente correcto "? Como se mencionó, parece que el vaciado de registros de GC y Linux puede pausar la ejecución, pero estoy seguro de que hay más cosas fuera de la aplicación Java que podrían causar un mal momento / rendimiento y hacer que cumpla con las estrictas limitaciones de la fecha límite. ¿Qué son?

Un software es en tiempo real, no cuando es lo más rápido posible, sino cuando se garantiza que un proceso se completa dentro de un intervalo de tiempo determinado. En un sistema blando de tiempo real, es bueno pero no absolutamente necesario que esto esté garantizado. Por ejemplo, en un juego, los cálculos necesarios para un cuadro deben completarse dentro del período de un cuadro, o la tasa de cuadros caerá. Esto degrada la calidad del juego, pero no lo hace incorrecto. Por ejemplo, Minecraft es divertido a pesar de que el juego tartamudea ocasionalmente.

En un sistema de tiempo real difícil, no tenemos tales libertades. Un software de control de vuelo debe reaccionar dentro de un plazo determinado, o el vehículo podría estrellarse. Y el hardware, el sistema operativo y el software deben trabajar juntos para admitir en tiempo real.

Por ejemplo, el sistema operativo tiene un planificador para decidir cuándo se ejecuta el subproceso. Para un programa en tiempo real, el planificador debe garantizar espacios de tiempo lo suficientemente grandes y frecuentes. Cualquier otro proceso que desee ejecutarse en dicho espacio debe interrumpirse a favor del proceso en tiempo real. Esto requiere un planificador con soporte explícito en tiempo real.

Además, un programa de espacio de usuario hará llamadas del sistema al núcleo. En un sistema operativo en tiempo real, estos también deben ser en tiempo real. Por ejemplo, escribir en un identificador de archivo tendría que garantizarse que no tomaría más de x unidades de tiempo, lo que resolvería el problema de registro. Esto afecta cómo se puede implementar una llamada de sistema de este tipo, por ejemplo, cómo se pueden usar los buffers. También significa que una llamada debe fallar si no puede completarse dentro del tiempo requerido, y que el programa de espacio de usuario debe estar preparado para manejar estos casos. En el caso de Java, la JVM y la biblioteca estándar también son similares al núcleo y necesitarían soporte explícito en tiempo real.

Para cualquier cosa que sea en tiempo real, su estilo de programación cambiará. Si no tiene tiempo interminable, debe restringirse a pequeños problemas. Todos tus bucles deben estar delimitados por alguna constante. Toda la memoria puede asignarse estáticamente, ya que tiene un límite superior en el tamaño. La recursión sin restricciones está prohibida. Esto va en contra de muchas de las mejores prácticas, pero no se aplican a sistemas en tiempo real. Por ejemplo, un sistema de registro podría usar un buffer de anillo asignado estáticamente para almacenar mensajes de registro cuando se escriben. Una vez que se alcanza el inicio, los registros antiguos se descartarían o esta condición podría ser un error.

De wikipedia :

Una característica clave de un RTOS es el nivel de consistencia con respecto a la cantidad de tiempo que lleva aceptar y completar la tarea de una aplicación; La variabilidad es jitter.

Lo importante es que la fluctuación de fase se cuantifica para que el sistema se considere en tiempo real . El artículo continúa diciendo que si el jitter generalmente está limitado, el sistema es suave en tiempo real . Si la fluctuación de fase siempre está limitada, el sistema es difícil en tiempo real .

A menos que las versiones de Java y Linux utilice se cuantifica en términos de fluctuación, que están no en tiempo real. La recolección de basura y la escritura de registros son ciertamente fuentes de fluctuación, pero incluso el procesamiento autónomo de (por ejemplo) paquetes de red cuenta si introduce fluctuación en sus procesos.

Para empezar, el Vanilla Linux en sí mismo no puede hacerlo en tiempo real. Por eso se desarrolló RTLinux .

Digamos que ejecuta algunos procesos java en RTLinux, todavía se considerarían en tiempo real ya que todos esos procesos están programados por el núcleo, es decir, si un proceso se retrasa, otros procesos aún pueden tener su porción de tiempo de CPU garantizada.

Ahora, si los procesos de Java ejecutan subprocesos verdes , entonces la ejecución de estos subprocesos ya no será en tiempo real ya que la JVM no realiza la programación en tiempo real.