Quais são as razões pelas quais uma pilha Java / Linux falha em "tempo real"?

Eu sempre ouvi os desenvolvedores mencionarem que o Java não pode " fazer em tempo real ", o que significa que um aplicativo Java em execução no Linux não pode atender aos requisitos de um sistema determinístico em tempo real, como algo em execução no RIOT-OS, etc.

Estou tentando entender o porquê . Meu SWAG me diz que isso provavelmente se deve principalmente ao Garbage Collector do Java, que pode ser executado a qualquer momento e pausar totalmente o sistema. E embora existam os chamados "GCs sem pausas" por aí, eu não acredito necessariamente na publicidade deles, e também não tenho uma instância de US $ 80 mil por JVM para gastar em um projeto de hobby!

Eu também estava lendo este artigo sobre a execução de software drone no Linux . Nesse artigo, o autor descreve um cenário em que o Linux quase fez com que seu drone colidisse com seu carro:

Aprendi uma lição difícil depois de escolher fazer o loop de controle de baixo nível (PIDs) no Pi - tentando ser inteligente, decidi colocar uma gravação de log no meio do loop para depuração - o quad inicialmente voou bem, mas o Linux decidiu levar 2 segundos para escrever uma entrada de log e o quadriciclo quase bateu no meu carro!

Agora, embora esse autor tenha escrito seu software drone em C ++, eu imaginaria que um aplicativo Java em execução no Linux poderia muito bem sofrer o mesmo destino.

De acordo com a Wikipedia:

Um sistema é considerado em tempo real se a correção total de uma operação depender não apenas de sua correção lógica, mas também do tempo em que é executada.

Então, para mim, isso significa " Você não tem tempo real se a correção total exigir correção lógica e pontualidade " .

Vamos fingir que escrevi um aplicativo Java para ter um desempenho excelente e que "apertei o limão" por assim dizer, e não podia ser razoavelmente escrito (em Java) para ser mais rápido.

Em suma, minha pergunta é: estou procurando alguém para me explicar todas / a maioria dos motivos pelos quais um aplicativo Java executando o Linux falharia em ser um "aplicativo em tempo real". Ou seja, quais são todas as categorias de coisas em uma pilha Java / Linux que impedem que "seja oportuna" e, portanto, " totalmente correta "? Como mencionado, parece que a liberação de log do GC e Linux pode pausar a execução, mas tenho certeza de que há mais coisas fora do próprio aplicativo Java que causariam mau tempo / desempenho e que atendam a restrições rígidas de prazo. O que eles são?

Um software é em tempo real, não quando é o mais rápido possível, mas quando é garantido que um processo é concluído dentro de um determinado intervalo de tempo. Em um sistema de tempo real suave, é bom, mas não absolutamente necessário, que isso seja garantido. Por exemplo, em um jogo, os cálculos necessários para um quadro devem ser concluídos dentro do período de um quadro, ou a taxa de quadros cairá. Isso degrada a qualidade da jogabilidade, mas não a torna incorreta. Por exemplo, o Minecraft é divertido, embora o jogo ocasionalmente gagueje.

Em um sistema rígido em tempo real, não temos tais liberdades. Um software de controle de vôo deve reagir dentro de algum prazo, ou o veículo pode travar. E o hardware, SO e software devem trabalhar juntos para oferecer suporte em tempo real.

Por exemplo, o sistema operacional possui um agendador para decidir quando o encadeamento será executado. Para um programa em tempo real, o agendador precisa garantir intervalos de tempo grandes o suficiente e freqüentes. Qualquer outro processo que queira executar nesse slot deve ser interrompido em favor do processo em tempo real. Isso requer um agendador com suporte explícito em tempo real.

Além disso, um programa de espaço do usuário fará chamadas do sistema no kernel. Em um sistema operacional em tempo real, eles também devem ser em tempo real. Por exemplo, a gravação em um identificador de arquivo teria que garantir não mais do que x unidades de tempo, o que resolveria o problema de log. Isso afeta o modo como uma chamada do sistema pode ser implementada, por exemplo, como os buffers podem ser usados. Isso também significa que uma chamada deve falhar se não puder ser concluída dentro do tempo necessário e que o programa de espaço do usuário deve estar preparado para lidar com esses casos. No caso de Java, a JVM e a biblioteca padrão também são semelhantes ao kernel e precisariam de suporte explícito em tempo real.

Para qualquer coisa em tempo real, seu estilo de programação mudará. Se você não tem tempo sem fim, deve se restringir a pequenos problemas. Todos os seus loops devem ser limitados por alguma constante. Toda a memória pode ser alocada estaticamente, desde que você tenha um limite superior no tamanho. A recursão irrestrita é proibida. Isso contraria muitas das melhores práticas, mas elas não se aplicam a sistemas em tempo real. Por exemplo, um sistema de log pode usar um buffer de anel alocado estaticamente para armazenar mensagens de log quando elas são gravadas. Quando a inicialização é alcançada, os logs antigos seriam descartados ou essa condição pode ser um erro.

Da wikipedia :

Uma característica fundamental de um RTOS é o nível de consistência referente à quantidade de tempo necessário para aceitar e concluir a tarefa de um aplicativo; a variabilidade é instável.

O importante é que o jitter seja quantificado para que o sistema seja considerado em tempo real . O artigo continua dizendo que, se o tremor geralmente é limitado, o sistema fica macio em tempo real . Se o tremor estiver sempre limitado, o sistema ficará em tempo real .

A menos que as versões do Java e Linux usadas sejam quantificadas em termos de jitter, elas não são em tempo real. A coleta de lixo e a gravação de log são certamente fontes de jitter, mas mesmo o processamento autônomo de (por exemplo) pacotes de rede conta se ele introduzir o jitter em seus processos.

Para começar, o próprio vanilla Linux não pode fazer em tempo real. É por isso que o RTLinux foi desenvolvido.

Digamos que você execute alguns processos java no RTLinux, eles ainda serão considerados em tempo real, pois todos esses processos são agendados pelo kernel, ou seja, se um processo estiver atrasado, outros processos ainda poderão ter sua fatia de tempo da CPU garantida.

Agora, se os processos java executam encadeamentos verdes , a execução desses encadeamentos não será mais em tempo real, pois a JVM não realiza o planejamento em tempo real.