Análise do artigo The Design and Performance of Real-Time Java Middleware Felipe Victoreti Humberto Vargas Gomes 31/05/2006 PPGC – UFRGS CMP167 – Programação com objetos distribuídos Prof. Cláudio Geyer

Tema Apresentação do jRate, uma implementação de um middleware Java com suporte a tempo real, desenvolvido de acordo com a RTSJ. Explicação sucinta das características da RTSJ. Resultados da comparação entre jRate versus RI (TimeSys) com o uso de um benchmarking suite RTJPerf

Motivação A grande maioria dos microprocessadores (90 %) são utilizados em aplicações embarcadas e de tempo real. Hardwares complexos requerem um crescente esforço de desenvolvimento de software. Necessidade de colocar produtos o mais rápido possível no mercado. Necessidade de linguagens de alto nível e ferramentas que acelerem o desenvolvimento de software.

Motivação Java se torna uma opção atrativa, por:  Simplicidade  Segurança  Baixo custo de manutenção  Fácil aprendizado  Em C/C++ problemas de gerenciamento de memória.

Problemas a resolver Java não é adequado a sistemas de tempo real por:  escalonamento das threads não especificado adequadamente.  linguagens com coletores de lixo (previsibilidade).  Java não prevê controle sobre o tipo de memória em que os objetos são alocados (aloca apenas na pilha).  tempos de alocação e liberação de memória não são previsíveis.

Solução RTSJ Adequação de Java a sistemas de tempo real: RTSJ (Real-Time Specification for Java):  Extende API Java e refina para suportar aplicações de tempo real.  novos modos de gerenciamento de memória: quanto ao tempo de vida: imortal, com escopo “scoped” onde os objetos não são coletados individualmente. quanto ao tempo de alocação: linear, variável.  acesso à memória externa (não apenas à pilha).  dois novos tipos de Threads para tempo real: RealTimeThread e NoHeapRealTimeThread: NoHeapRealTimeThread pode ter prioridade superior ao garbage collector (nem aloca nem referencia obj na pilha).

Solução RTSJ  escalonamento: objetos escalonáveis, execução controlada por vários modos: Earliest Deadline First (EDF), Rate Monotonic (RM), etc.  eventos assíncronos: capacidade de associar eventos internos ou externos à execução de determinada lógica.  AsyncEventHandler: não possui uma thread permanentemente, ao ocorrer uma nova será criada.  BoundAsyncEventHandler: possui uma thread permanentemente associada ao evento (rápido)  Timers: oneshottimer: gera evento quando tempo associado expira; periodictimer: gera eventos periodicamente;

jRate jRate é baseada na especificação RTSJ de um middleware Java para sistemas de tempo real compila aplicações RTSJ em código nativo; suporta memória com escopo e imortal; suporta estratégias de alocação (tempo linear, tempo variável); implementa escalonamento e threads para execução em tempo real: RealTimeThread; implementa um robusto e eficiente sistema para tratamento de eventos assíncronos (evita inversão de prioridades e despacho “lock free” );

jRate timers periódicos e oneshot (uma thread por timer); Não há JVM interpretando Java bytecode; Serviços Java acessível por GCJ e serviços RTSJ acessíveis pelo jRate.

Resultados e comparações Ensaios no mesmo computador PentiumIII 733MHz 256MB RAM com Linux RH7.3 e e um pacote de para benchmark de aplicações TR (RTJPerf).  Testes executados no mínimo 1000 vezes.  Medidos os valores médios, pior caso, 99% e dispersão. Ensaio de tempo de alocação com diversos tamanhos de memória (32bytes a 16 KB) Teste em memórias com escopo: tempo necessário para criar, para entrar e para sair; tempo para chaveamento de contexto entre threads; tempo ativação periódica de threads (1ms a 500ms) tempo desde um evento assíncrono até o atendimento ;

Resultados e comparações conclusão jRate tem características que o torna superior em todos os testes quando comparado à implementação RI Em alguns casos, mais que uma ordem de grandeza, como no tempo de criação de threads (jRate us, RI 1276 us), e nos tempos de atendimento de eventos assíncronos, Asynceventhandler (jRate us, RI 2953 us).

Resultados e comparações conclusão A comparação com C++ foi feita em um item apenas, C++ foi mais eficiente, mas jRate ficou próximo (jRate 1.45 us e C us) jRate parece uma boa alternativa para o desenvolvimento de aplicações em tempo real. Comparação complicada pois jRate gera software compilado em código nativo e RI é interpretado (seria mais justo comparar jRate com C++ e não com RI) Outra característica não mencionada é qual o tamanho do código gerado? Qual é a necessidade de memória RAM do middleware?

Avaliação do grupo Motivação: 5 Problemas solucionados: 5 Protótipo: 5 Resultados: 5 Comparação com outros trabalhos: 2 Redação: 4

Bibliografia R. Jones; R. Lins, “Garbage Collection Algorithms for Automatic Dynamic Memory Management”. New York: Wiley e Sons, G. Bollella; J. Gosling; B.Brosgol; P.Dibble; S. Furr; D. Hardin; M. Turnbull, “The Real Time Specification for Java”. Addision-Wesley TimeSys, Real-Time Specification for Java Reference Implementation, R. Meersman; Z. Tari, “The Design and Performance of the jRate Real-Time Java Implementation”. A. Corsaro; R.K. Cytron, “Efficient Memory-Reference Checks for Real- Time Java”. Conference Language, Compiler and Tool for Embedded Systems p 51-58, 2003 D.C. Schmidt; M; Deshpande; C. O´Ryan, “Operating System Performance in Support of Real-Time Middleware”, Jan J. Lawson, “Real-Time Java for Embedded Systems (RTJES)”,