Jazelle - Jazelle
Jazelle DBX (execução direta de bytecode) é uma extensão que permite que alguns processadores ARM executem bytecode Java em hardware como um terceiro estado de execução junto com os modos ARM e Thumb existentes . A funcionalidade Jazelle foi especificada na arquitetura ARMv5TEJ e o primeiro processador com tecnologia Jazelle foi o ARM926EJ-S . Jazelle é denotado por um "J" acrescentado ao nome da CPU, exceto para núcleos pós-v5 onde é necessário (embora apenas na forma trivial) para conformidade de arquitetura.
Jazelle RCT (Runtime Compilation Target) é uma tecnologia diferente e é baseada no modo ThumbEE e suporta a compilação antecipada (AOT) e just-in-time (JIT) com Java e outros ambientes de execução.
O uso mais proeminente do Jazelle DBX é por fabricantes de telefones celulares para aumentar a velocidade de execução de jogos e aplicativos Java ME . Uma Java virtual machine (JVM) compatível com Jazelle tentará executar bytecode Java no hardware, enquanto retorna ao software para operações de bytecode mais complicadas ou menos usadas. ARM afirma que aproximadamente 95% do bytecode no uso típico do programa acaba sendo processado diretamente no hardware.
As especificações publicadas são muito incompletas, sendo suficientes apenas para escrever o código do sistema operacional que pode suportar uma JVM que usa Jazelle. A intenção declarada é que apenas o software JVM precisa (ou tem permissão para) depender dos detalhes da interface de hardware. Essa ligação estreita facilita que o hardware e a JVM possam evoluir juntos sem afetar outro software. Na verdade, isso dá à ARM Holdings um controle considerável sobre quais JVMs podem explorar o Jazelle. Também evita que JVMs de software livre usem Jazelle. Esses problemas não se aplicam ao ambiente ARMv7 ThumbEE, o sucessor nominal do Jazelle DBX.
Implementação
A extensão Jazelle usa tradução binária de baixo nível , implementada como um estágio extra entre os estágios de busca e decodificação no pipeline de instrução do processador . Bytecodes reconhecidos são convertidos em uma sequência de uma ou mais instruções ARM nativas.
O modo Jazelle move a interpretação JVM para o hardware para as instruções JVM simples mais comuns. Isso visa reduzir significativamente o custo de interpretação. Entre outras coisas, isso reduz a necessidade de compilação Just-in-time e outras técnicas de aceleração de JVM. As instruções JVM que não são implementadas no hardware Jazelle fazem com que as rotinas apropriadas na implementação de JVM compatível com Jazelle sejam chamadas. Os detalhes não são publicados, uma vez que todas as partes internas da JVM são transparentes (exceto para desempenho) se interpretadas corretamente.
O modo Jazelle é inserido através das instruções BXJ. Uma implementação de hardware do Jazelle cobrirá apenas um subconjunto de bytecodes JVM. Para bytecodes não manipulados - ou se substituído pelo sistema operacional - o hardware invocará o software JVM. O sistema é projetado de forma que o software JVM não precise saber quais bytecodes estão implementados no hardware e um fallback de software é fornecido pelo software JVM para o conjunto completo de bytecodes.
Conjunto de instruções
O conjunto de instruções Jazelle é bem documentado como bytecode Java . No entanto, o ARM não divulgou detalhes sobre os detalhes exatos do ambiente de execução; a documentação fornecida com o HotSpot Java Virtual Machine da Sun vai mais longe ao afirmar: "Para evitar dúvidas, distribuição de produtos contendo código de software para exercer a instrução BXJ e permitir o uso da extensão de arquitetura ARM Jazelle sem acordo [..] da ARM é expressamente proibido. "
Os funcionários da ARM publicaram no passado vários white papers que fornecem algumas boas dicas sobre a extensão do processador. As versões do Manual de referência da arquitetura ARM disponíveis a partir de 2008 incluíram pseudocódigo para a instrução "BXJ" (Branch e eXchange to Java), mas com os detalhes mais precisos sendo mostrados como "SUBARQUITETURA DEFINIDA" e documentados em outro lugar.
Interface binária do aplicativo (ABI)
O estado Jazelle depende de uma convenção de chamada acordada entre o JVM e o estado de hardware Jazelle. Esta interface binária do aplicativo não é publicada pela ARM, tornando o Jazelle um recurso não documentado para a maioria dos usuários e JVMs de Software Livre.
Todo o estado da VM é mantido dentro de registros ARM normais, permitindo compatibilidade com sistemas operacionais existentes e manipuladores de interrupção não modificados. Reiniciar um bytecode (como seguir um retorno de uma interrupção) irá reexecutar a seqüência completa de instruções ARM relacionadas.
Registradores específicos são designados para conter as partes mais importantes do estado da JVM: os registros R0 – R3 contêm um alias do topo da pilha Java, R4 contém o operando local Java zero (ponteiro para *this) e R6 contém o ponteiro da pilha Java.
O Jazelle reutiliza o contador de programa existente no PC ou seu registro sinônimo R15. Um ponteiro para o próximo bytecode vai em R14, então o uso do PC geralmente não é visível para o usuário, exceto durante a depuração.
CPSR: Indicação de modo
O bytecode Java é indicado como a instrução atual definida por uma combinação de dois bits no ARM CPSR (Current Program Status Register). O bit "T" deve ser apagado e o bit "J" definido.
Bytecodes são decodificados pelo hardware em dois estágios (versus um único estágio para código Thumb e ARM) e alternar entre a decodificação de hardware e software (modo Jazelle e modo ARM) leva cerca de 4 ciclos de clock.
Para que a entrada no estado de hardware Jazelle seja bem-sucedida, o bit JE (Jazelle Enable) no registro CP14: C0 (C2) [bit 0] deve ser definido; limpar o bit JE por um sistema operacional [privilegiado] fornece uma substituição de alto nível para evitar que programas de aplicativos usem a aceleração de hardware Jazelle. Além disso, o bit CV (configuração válida) encontrado em CP14: c0 (c1) [bit 1] deve ser definido para mostrar que há uma configuração de estado Jazelle consistente para o hardware usar.
BXJ: Ramificação para Java
A instrução BXJ tenta mudar para o estado Jazelle e, se permitido e bem-sucedido, define o bit "J" no CPSR; caso contrário, "falha" e atua como uma instrução BX ( Ramificação ) padrão . O único momento em que um sistema operacional ou depurador deve estar totalmente ciente do modo Jazelle é ao decodificar uma instrução com falha ou interceptada. O contador do programa Java (PC) que aponta para as próximas instruções deve ser colocado no Link Register (R14) antes de executar a solicitação de ramal BXJ, pois independente do processamento de hardware ou software, o sistema deve saber por onde iniciar a decodificação.
Como o estado atual é mantido no CPSR, o conjunto de instruções de bytecode é automaticamente selecionado novamente após a alternância de tarefas e o processamento do bytecode Java atual é reiniciado.
Após uma entrada no modo de estado Jazelle, os bytecodes podem ser processados de uma das três maneiras: decodificados e executados nativamente em hardware, manipulados em software (com código JVM ARM / ThumbEE otimizado) ou tratados como um opcode inválido / ilegal. O terceiro caso causará uma ramificação para um modo de exceção ARM, assim como um bytecode Java de 0xff, que é usado para definir pontos de interrupção JVM.
A execução continuará no hardware até que um bytecode não tratado seja encontrado ou até que ocorra uma exceção. Entre 134 e 149 bytecodes (de 203 bytecodes especificados na especificação JVM) são traduzidos e executados diretamente no hardware.
Registros de baixo nível
Os registros de configuração de baixo nível, para a máquina virtual de hardware, são mantidos no coprocessador ARM "registro CP14 c0". Os registros permitem detectar, habilitar ou desabilitar o acelerador de hardware (se disponível).
- O Jazelle Identity Register no registro CP14: C0 (C0) é somente leitura acessível em todos os modos.
- O Jazelle OS Control Register em CP14: c0 (c1) só está acessível no modo kernel e causará uma exceção quando acessado no modo de usuário.
- O Jazelle Main Configuration Register em CP14: C0 (C2) é somente gravação no modo de usuário e leitura-gravação no modo kernel.
Uma implementação de hardware "trivial" do Jazelle (como encontrada no emulador QEMU ) é necessária apenas para suportar o código de operação BXJ em si (tratando BXJ como uma instrução BX normal) e retornar RAZ (leitura como zero) para todos os CP14 : c0 Registros relacionados ao Jazelle.
Sucessor: ThumbEE
A arquitetura ARMv7 tirou a ênfase da execução Jazelle e Direct Bytecode de bytecodes JVM. Em termos de implementação, apenas o suporte de hardware trivial para Jazelle agora é necessário: suporte para entrar e sair do modo Jazelle, mas não para executar quaisquer bytecodes Java.
Em vez disso, o Thumb Execution Environment ( ThumbEE ) era o preferido, mas desde então também foi descontinuado. O suporte para ThumbEE era obrigatório em processadores ARMv7-A (como Cortex-A8 e Cortex-A9), e opcional em processadores ARMv7-R. ThumbEE direcionado a ambientes compilados, talvez usando tecnologias JIT . Não era específico do Java e foi totalmente documentado; uma adoção muito mais ampla foi antecipada do que Jazelle foi capaz de alcançar.
ThumbEE era uma variante do conjunto de instruções Thumb2 de 16/32 bits. Ele integrou a verificação de ponteiro nulo; definiu alguns novos mecanismos de falha; e reaproveitou o espaço de opcode LDM e STM de 16 bits para suportar algumas instruções, como verificação de intervalo, um novo esquema de invocação de manipulador e muito mais. Da mesma forma, os compiladores que produziram código Thumb ou Thumb2 podem ser modificados para funcionar com ambientes de tempo de execução baseados em ThumbEE.