Jazelle DBX (ejecución directa de código de bytes ) [1] es una extensión que permite a algunos procesadores ARM ejecutar código de bytes Java en hardware como un tercer estado de ejecución junto con los modos ARM y Thumb existentes . [2] La funcionalidad de Jazelle se especificó en la arquitectura ARMv5TEJ [3] y el primer procesador con tecnología Jazelle fue el ARM926EJ-S . [4] Jazelle se denota con una "J" adjunta al nombre de la CPU, excepto para los núcleos posteriores a la v5 donde se requiere (aunque solo en forma trivial) para la conformidad de la arquitectura.
Jazelle RCT (Runtime Compilation Target) es una tecnología diferente y se basa en el modo ThumbEE y admite la compilación anticipada (AOT) y justo a tiempo (JIT) con Java y otros entornos de ejecución.
El uso más destacado de Jazelle DBX es por parte de los fabricantes de teléfonos móviles para aumentar la velocidad de ejecución de los juegos y aplicaciones Java ME . [ cita requerida ] Una máquina virtual Java (JVM) compatible con Jazelle intentará ejecutar el código de bytes de Java en el hardware, mientras regresa al software para operaciones de código de bytes más complicadas o menos utilizadas. ARM afirma que aproximadamente el 95% del código de bytes en el uso típico del programa termina siendo procesado directamente en el hardware.
Las especificaciones publicadas son muy incompletas, siendo solo suficientes para escribir código de sistema operativo que pueda soportar una JVM que use Jazelle. [ cita requerida ] La intención declarada es que solo el software JVM necesita (o está permitido) depender de los detalles de la interfaz del hardware. Este vínculo estrecho facilita que el hardware y la JVM puedan evolucionar juntos sin afectar a otro software. En efecto, esto le da a ARM Holdings un control considerable sobre qué JVM pueden explotar Jazelle. [ cita requerida ] También evita que las JVM de código abierto utilicen Jazelle. Estos problemas no se aplican al entorno ARMv7 ThumbEE, el sucesor nominal de Jazelle DBX.
Implementación
La extensión Jazelle utiliza traducción binaria de bajo nivel , implementada como una etapa adicional entre las etapas de recuperación y decodificación en la canalización de instrucciones del procesador . Los códigos de bytes reconocidos se convierten en una cadena de una o más instrucciones ARM nativas.
El modo Jazelle traslada la interpretación de JVM al hardware para las instrucciones más comunes de JVM simples. Esto tiene la intención de reducir significativamente el costo de interpretación. Entre otras cosas, esto reduce la necesidad de compilación Just-in-time y otras técnicas de aceleración de JVM. [5] Las instrucciones de JVM que no están implementadas en el hardware de Jazelle hacen que se invoquen las rutinas adecuadas en la implementación de JVM compatible con Jazelle. Los detalles no se publican, ya que todas las entrañas de la JVM son transparentes (excepto el rendimiento) si se interpretan correctamente.
El modo Jazelle se ingresa a través de las instrucciones BXJ. Una implementación de hardware de Jazelle solo cubrirá un subconjunto de códigos de bytes de JVM. Para códigos de bytes no controlados, o si el sistema operativo lo reemplaza, el hardware invocará la JVM de software. El sistema está diseñado para que el software JVM no necesite saber qué códigos de bytes están implementados en el hardware y el software JVM proporciona un respaldo de software para el conjunto completo de códigos de bytes.
Conjunto de instrucciones
El conjunto de instrucciones de Jazelle está bien documentado como código de bytes de Java . Sin embargo, ARM no ha publicado detalles sobre los detalles exactos del entorno de ejecución; la documentación proporcionada con la máquina virtual Java HotSpot de Sun llega a afirmar: "Para evitar dudas, la distribución de productos que contienen código de software para ejercitar la instrucción BXJ y permitir el uso de la extensión de la arquitectura ARM Jazelle sin [..] acuerdo de ARM está expresamente prohibido ". [6]
Los empleados de ARM han publicado en el pasado varios documentos técnicos que brindan buenos consejos sobre la extensión del procesador. [ cita requerida ] Las versiones del Manual de referencia de ARM Architecture disponibles desde 2008 han incluido pseudocódigo para la instrucción "BXJ" (Branch and eXchange to Java), pero los detalles más finos se muestran como "SUBARQUITECTURA DEFINIDA" y documentada en otro lugar.
Interfaz binaria de aplicación (ABI)
El estado de Jazelle se basa en una convención de llamadas acordada entre la JVM y el estado de hardware de Jazelle. Esta interfaz de aplicación binaria no es una publicación de ARM, lo que hace Jazelle una característica no documentada para la mayoría de usuarios de software libre y las JVM.
Todo el estado de la máquina virtual se mantiene dentro de los registros ARM normales, lo que permite la compatibilidad con los sistemas operativos existentes y los controladores de interrupciones sin modificaciones. Reiniciar un código de bytes (como seguir un retorno de una interrupción) volverá a ejecutar la secuencia completa de instrucciones ARM relacionadas.
Los registros específicos están diseñados para contener las partes más importantes del estado de JVM: los registros R0 – R3 contienen un alias de la parte superior de la pila de Java, R4 contiene el operando local de Java cero (puntero a *this
) y R6 contiene el puntero de pila de Java. [7]
Jazelle reutiliza el PC contador de programas existente o su registro de sinónimos R15. Un puntero al siguiente código de bytes va en R14, [8] por lo que el uso de la PC generalmente no es visible para el usuario, excepto durante la depuración.
CPSR: indicación de modo
El código de bytes de Java se indica como la instrucción actual establecida por una combinación de dos bits en ARM CPSR (Registro de estado del programa actual). El bit "T" debe borrarse y el bit "J" debe establecerse. [9]
Los códigos de bytes son decodificados por el hardware en dos etapas (versus una sola etapa para el código Thumb y ARM) y el cambio entre la decodificación de hardware y software (modo Jazelle y modo ARM) toma ~ 4 ciclos de reloj. [10]
Para que la entrada al estado de hardware de Jazelle tenga éxito, se debe establecer el bit JE (Jazelle Enable) [3] en el registro CP14: C0 (C2) [bit 0]; la eliminación del bit JE mediante un sistema operativo [privilegiado] proporciona una anulación de alto nivel para evitar que los programas de aplicación utilicen la aceleración Jazelle de hardware. [11] Además, el bit [3] CV (configuración válida) que se encuentra en CP14: c0 (c1) [bit 1] [11] debe establecerse para mostrar que existe una configuración de estado de Jazelle consistente para que el hardware lo utilice.
BXJ: rama a Java
La instrucción BXJ intenta cambiar al estado Jazelle y, si se permite y tiene éxito, establece el bit "J" en el CPSR; de lo contrario, "falla" y actúa como una instrucción BX ( rama ) estándar . [3] El único momento en el que un sistema operativo o un depurador debe ser plenamente consciente del modo Jazelle es al decodificar una instrucción fallida o atrapada. El contador de programa Java (PC) que apunta a las siguientes instrucciones debe colocarse en el Registro de enlace (R14) antes de ejecutar la solicitud de rama BXJ, ya que independientemente del procesamiento del hardware o software, el sistema debe saber dónde comenzar la decodificación.
Debido a que el estado actual se mantiene en el CPSR, el conjunto de instrucciones de código de bytes se vuelve a seleccionar automáticamente después de que se reinicia la conmutación de tareas y el procesamiento del código de bytes de Java actual. [7]
Después de una entrada en el modo de estado de Jazelle, los códigos de bytes se pueden procesar de una de estas tres formas: decodificados y ejecutados de forma nativa en hardware, manejados en software (con código ARM / ThumbEE JVM optimizado) o tratados como un código de operación no válido / ilegal. El tercer caso provocará una bifurcación a un modo de excepción ARM, al igual que un código de bytes de Java de 0xff, que se utiliza para establecer puntos de interrupción de JVM. [12]
La ejecución continuará en el hardware hasta que se encuentre un código de bytes no controlado o se produzca una excepción. Entre 134 y 149 códigos de bytes (de 203 códigos de bytes especificados en la especificación JVM) se traducen y ejecutan directamente en el hardware.
Registros de bajo nivel
Los registros de configuración de bajo nivel, para la máquina virtual de hardware, se mantienen en el coprocesador ARM "registro CP14 c0". Los registros permiten detectar, habilitar o deshabilitar el acelerador de hardware (si está disponible). [13]
- El registro de identidad de Jazelle en el registro CP14: C0 (C0) es accesible de solo lectura en todos los modos.
- El registro de control de Jazelle OS en CP14: c0 (c1) solo es accesible en modo kernel y provocará una excepción cuando se acceda en modo usuario.
- El registro de configuración principal de Jazelle en CP14: C0 (C2) es de solo escritura en el modo de usuario y de lectura y escritura en el modo de kernel.
Solo se requiere una implementación de hardware "trivial" de Jazelle (como se encuentra en el emulador QEMU ) para admitir el código de operación BXJ en sí (tratando BXJ como una instrucción BX normal [3] ) y para devolver RAZ (lectura como cero) para todos del CP14: c0 registros relacionados con Jazelle. [14]
Sucesor: ThumbEE
La arquitectura ARMv7 ha restado importancia a Jazelle y a la ejecución directa de bytecode de los bytecodes de JVM. En términos de implementación, ahora solo se requiere un soporte de hardware trivial para Jazelle: soporte para ingresar y salir del modo Jazelle, pero no para ejecutar ningún código de bytes de Java.
En cambio, se prefería el entorno de ejecución de pulgar ( ThumbEE ), pero desde entonces también ha quedado obsoleto. La compatibilidad con ThumbEE era obligatoria en los procesadores ARMv7-A (como Cortex-A8 y Cortex-A9) y opcional en los procesadores ARMv7-R. ThumbEE apuntó a entornos compilados, quizás utilizando tecnologías JIT . No era en absoluto específico de Java y estaba completamente documentado; Se anticipó una adopción mucho más amplia de la que Jazelle pudo lograr.
ThumbEE era una variante del conjunto de instrucciones Thumb2 de 16/32 bits. Integró comprobación de puntero nulo; definió algunos nuevos mecanismos de falla; y reutilizó el espacio de código de operación LDM y STM de 16 bits para admitir algunas instrucciones, como la verificación de rango, un nuevo esquema de invocación de controlador y más. En consecuencia, los compiladores que produjeron código Thumb o Thumb2 podrían modificarse para trabajar con entornos de tiempo de ejecución basados en ThumbEE.
Referencias
- ^ Patente 7089539 - Interpretación de instrucciones del programa Patente estadounidense 7089539 - Interpretación de instrucciones del programa
- ^ https://web.archive.org/web/20140328171422/https://www.arm.com/products/processors/technologies/jazelle.php
- ^ a b c d e Manual de referencia de arquitectura ARM
- ^ Shanghai Jade Licenses ARM Prime Starter Kit para DCP SoC
- ^ CPM Design Online: uso de extensiones de hardware ARM DBX para acelerar Java en aplicaciones integradas con limitaciones de espacio
- ^ Sun, Hotspot, Notas de la versión Implementación de CLDC HotSpotTM Versión 2.0
- ^ a b Informe técnico de ARM, Acelerando para enfrentar el desafío de Java integrado
- ^ Intel, introducción a la arquitectura ARM. Vínculo muerto, febrero de 2020
- ^ Marinas, Catalin (4 de junio de 2007). "Re: [RFC] [PATCH] Agregar información de estado de ARM Jazelle en show_regs tombstone" . linux-arm-kernel (lista de correo) . Consultado el 5 de junio de 2020 .
- ^ Informe técnico de ARM, Java de alto rendimiento en dispositivos integrados
- ^ a b Manual de referencia de ARM (japonés), ARM ア ー キ テ ク チ ャ リ フ ァ レ ン ス マ ニ ュ ア ル
- ^ ARM, ARM1026EJ-S Manual de referencia técnica
- ^ Manual de referencia de ARM, comprensión de los modos de ahorro de energía del procesador ARM11
- ^ Referencia de ARM, Manual de referencia técnica de Cortex-A8