1 Introdução

Tipicamente, para alcançar os requisitos de performance e tamanho da aplicação, os fabricantes de dispositivos embedded utilizam um sistema operacional de tempo real (RTOS), além de ferramentas proprietárias, otimizadas para as limitações de memória apresentadas por estes dispositivos. Com o aumento da maturidade no desenvolvimento destes sistema, os fabricantes migraram de linguagens de baixo nível, como o Assembler, para linguagens com maior nível de abstração, como o C++. Contudo, os programas produzidos nestas linguagens ainda são altamente dependentes do sistema operacional e da plataforma alvo, o que dificulta a sua reutilização.

A necessidade de otimizar o processo de desenvolvimento dos sistemas embedded, através da construção de programas bem estruturados e com um alto fator de reusabilidade, tem estimulado a utilização da linguagem Java [1; 7]. Dentre os fatores que contribuem para a sua popularidade, alguns merecem um maior destaque:

• Portabilidade: o ambiente de execução Java permite a construção de programas independentes de plataforma;
• Reusabilidade: as características de orientação a objetos e independência de plataforma do Java permitem a migração direta de módulos de programas;
• Simplicidade: Java é uma linguagem de fácil aprendizado, além de eliminar os problemas com ponteiros (fator comum de erro);
• Segurança: os requisitos de encapsulamento presentes na linguagem permitem uma execução segura.

2 EmbeddedJava

2.1 Visão Geral

Diferentemente das plataformas Java e PersonalJava (que necessitam do conjunto completo de APIs para executar), o EJAE permite configurar as APIs de acordo com os requisitos da aplicação, possibilitando a sua utilização em dispositivos com pequenas quantidade de memória.
 

2.2 Arquitetura do EJAE

Segundo a especificação do EmbeddedJava [3], podem ser utilizadas nas aplicações qualquer campo ou método proveniente das APIs do JDK 1.1.7 (exceto java.applet). Isto permite ao desenvolvedor utilizar toda a robustez das APIs Java, mas também oferece a possibilidade de reduzi-las de acordo com as necessidades da aplicação. Para tanto, a Sun oferece ferramentas de otimização para criação do ambiente e para conversão do código em uma representação mais condensada. Uma vez que as aplicações são escritas na linguagem Java, módulos de programas ou até uma aplicação completa podem ser posteriormente migradas para novas plataformas e facilmente reusadas, independente do RTOS ou processador subjacente. Na figura 2 é exibida a divisão em camadas de uma aplicação EmbeddedJava.

Figura 2: Camadas de uma aplicação EmbeddedJava

2.3 Desenvolvimento de Aplicações no EJAE

Figura 3: Processo de desenvolvimento de uma aplicação EJAE

Analisando a figura 3, verifica-se que o primeiro passo para o desenvolvimento de uma aplicação no EJAE é a construção de um programa que faça referência a alguma das classes da API do EmbeddedJava. Posteriormente, esta aplicação servirá de entrada para a ferramenta JavaFilter. Esta última analisa as dependências estáticas entre os elementos do programa e a JVM. Como saída é produzida uma lista das classes, campos e métodos utilizados, que servirá de entrada para o JavaCodeCompact.

O JavaCodeCompact realiza otimizações exaustivas para reduzir a quantidade de memórias RAM e ROM necessárias no ambiente da aplicação. Esta ferramenta funciona como um pré-carregador, antecipando-se a criação das estruturas internas, eliminando as redundâncias para economizar espaço e resolvendo as referências simbólicas. As estruturas de dados produzidas estão no formato de código fonte C, possibilitando a sua representação de maneira independente de plataforma.

Finalmente, as estruturas de dados produzidas pelas ferramentas são compiladas, juntamente com qualquer outro código nativo, usando o compilador C para o sistema operacional do dispositivo alvo. Os códigos objeto resultantes são linkados para produzir uma imagem executável compacta do EmbeddedJava., que pode ser inserida na ROM do dispositivo.

O processo citado, considerando a eficiência das ferramentas do EmbeddedJava, permite aos fabricantes configurar e construir ambientes de execução Java altamente otimizados para dispositivos embedded de pequena quantidade de memória.

2.4 Passos Futuros do EJAE

3 Real-Time Java

3.1 Visão Geral

Diferente dos ambientes Java tradicionais, o Real-Time Java permite aos desenvolvedores a escrita de códigos que requisitem o cumprimento seguro das restrições temporais impostas na aplicação. Para tanto são oferecidas um conjunto de APIs especiais [9] provenientes de um ambiente denominado PERC (Portable Executive for Reliable Control). O cumprimento das restrições impostas se dá através da implementação de uma Máquina Virtual Java especial, denominada PERC virtual machine [8].

3.2 PERC Virtual Machine 1.0

As principais propriedades da PERC-VM podem ser vistas a seguir:

• Coletor de lixo tempo-real: o coletor de lixo (garbage collection) implementado pela PERC-VM possui um controle preciso sobre a fragmentação de memória produzida. Diferente da máquina virtual tradicional, esta implementação não deixa falhas entre os trechos de memória alocados, resultantes da reorganização conservativa. Os objetos ativos são copiados de modo incremental para trechos de memória contínuos a fim de eliminar os fragmentos livres. Outra consideração importante é que o coletor de lixo pode ser preemptado por uma tarefa de maior prioridade, resumindo a partir do ponto em que o mesmo foi desescalonado. Isto se opõem à implementação tradicional, do tipo run-to-completition, onde o coletor de lixo tem baixa prioridade e, quando escalonado, deve terminar toda a otimização.
• Execução determinística: o escalonador da PERC-VM utiliza uma política de escalonamento round-robin com prioridades fixas (prioridades não se alteram com o passar do tempo). Além disso, as filas de espera associadas com os monitores são ordenadas por prioridade, com o monitor adotando herança de prioridades para reduzir a problemática da inversão de prioridades.
• Configuração e customização: uma vez que cada aplicação possui um conjunto de necessidades próprias, a PERC-VM pode ser customizada através de ferramentas que minimizam a quantidade de memória ocupada.

3.3 PERC Real-Time API 1.0

• Timed: identifica um segmento de código cuja execução tem tempo limitado ou deadline associado (vide fig. 4a).
• Atomic: identifica um segmento de código atômico (vide fig. 4b), i.e. ou a execução é realizada por completo ou não é efetuada. Adicionalmente, atomicidade implica em sincronização em termos de objetos dentro do qual o segmento de código atômico aparece.

Timed(Time.us(30)) {                                    atomic {
     boundedCode();                                           arbitraryCode();
}                                                                   }
            a)                                                                b)

Um programa Java-RT consiste de um número arbitrário de atividades tempo-real, acompanhadas por um número arbitrário de threads executáveis, que não possuem restrições temporais associadas. Neste ambiente existem quatro tipos diferentes de atividades tempo-real, que podem ser individualmente caracterizadas como cíclicas, esporádicas, espontâneas ou ongoing. As definições de cada uma destas atividades são mostradas a seguir:

1. As tarefas periódicas ou cíclicas são invocadas em períodos regulares fixos durante o decorrer da execução da atividade de tempo real.
2. As tarefas esporádicas, por outro lado, não têm um período de execução fixo. Estas tarefas ocorrem em resposta a eventos externos. Quando as respostas a estes eventos são processadas dentro de um tempo específico, a tarefa é descrita como sendo uma tarefa de tempo real esporádica.
3. Tarefas espontâneas são similares às esporádicas pois também atuam em resposta a eventos externos. Porém não há limite máximo na freqüência de execução destas tarefas. O executivo de tempo real permite a execução deste tipo de tarefa somente se existirem recursos suficientes para tal.
4. As tarefas contínuas ou ongoing, diferentemente dos outros tipos de tarefas, caracterizam-se por serem suspensas e retomadas, em vez de reiniciadas a cada período de execução da atividade.

3.4 Desenvolvimento de Aplicações PERC

A segunda técnica para a tradução do código PERC consiste do uso de um compilador especial Java chamado Percolator^TM, que combina a funcionalidade do p2jpp e do JavaC. A vantagem do Percolator está na análise adicional do código PERC, sendo que do código resultante desta análise é gerado o byte-code em arquivos .class. O propósito desta análise está na assistência da verificação do pior tempo de execução (worst case execution time), sendo eficiente na identificação do segmento de código que executa este tempo e também na identificação dos caminhos da execução do pior caso, correspondente a cada um dos segmentos de código.

Além disso, o código gerado pelo compilador Percolator, sugere que seja habilitado o tradutor JIT da máquina virtual, para a geração de um código mais eficiente. Estas sugestões são representadas como atributos de métodos Java dentro dos arquivos .class, cuja presença destes atributos não impede que o código seja executado através da máquina virtual Java tradicional. Isso só acontece porque a especificação oficial da máquina virtual Java exige que ela ignore qualquer atributo não reconhecido.

4 Comparação PERC vs EJAE

Como principal diferença entre os ambientes cita-se a maneira como o PERC implementa o coletor de lixos, o que possibilita um bom desenpenho durante a execução da aplicação. Além disso, a política de escalonamento adotada permite garantir a satisfação dos requisitos temporais impostos no programa. Em relação às bibliotecas utilizadas, considera-se o EJAE mais avançado pois ao contrário do PERC, faz uso de uma biblioteca Java bastante atualizada, além de ser otimizada para dispositivos com restrições de memória. Por fim, cabe salientar que o PERC implementa algumas primitivas extras para a linguagem Java, o que permite a descrição de tarefas tempo-real.
 

5 Conclusões

Ao final deste trabalho verifica-se que o ambiente PERC encotra-se num estágio de desenvolvimento mais avançado, uma vez que foram realizadas novas implementações na máquina virtual Java da Sun a fim de suportar os requisitos temporais e de recursos existentes. Como desvantagem do PERC em relação ao EJAVA cita-se o fato do primeiro fazer uso de uma implementação muito antiga do JVM, o que impede a utilização de novos recursos como o RMI. Desta forma, idealiza-se que o ambiente ideal seja uma unificação dos ambientes pesquisados.
 

6 Bibliografia