Jazelle DBX (ejecución directa de bytecode) [1] es una extensión que permite a algunos procesadores ARM ejecutar bytecode 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 por una "J" adjunta al nombre de la CPU, excepto para los núcleos posteriores a la versión 5, donde se requiere (aunque solo en forma trivial) para la conformidad con la arquitectura.
Jazelle RCT (Runtime Compilation Target) es una tecnología diferente basada en el modo ThumbEE; 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 bytecode de Java en el hardware, mientras vuelve al software para operaciones de bytecode más complicadas o menos utilizadas. ARM afirma que aproximadamente el 95% del bytecode en el uso típico de un programa termina siendo procesado directamente en el hardware.
Las especificaciones publicadas son muy incompletas, siendo sólo suficientes para escribir código de sistema operativo que pueda soportar una JVM que use Jazelle. [ cita requerida ] La intención declarada es que sólo el software de la JVM necesita (o se le permite) depender de los detalles de la interfaz de hardware. Esta estrecha vinculación facilita que el hardware y la JVM evolucionen 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 usen Jazelle. Estos problemas no se aplican al entorno ARMv7 ThumbEE, el sucesor nominal de Jazelle DBX.
La extensión Jazelle utiliza una traducción binaria de bajo nivel , implementada como una etapa adicional entre las etapas de búsqueda y decodificación en la secuencia de instrucciones del procesador . Los códigos de bytes reconocidos se convierten en una cadena de una o más instrucciones nativas de ARM.
El modo Jazelle traslada la interpretación de la JVM al hardware para las instrucciones JVM simples más comunes. Esto tiene como objetivo 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 la JVM. [5] Las instrucciones JVM que no están implementadas en el hardware Jazelle hacen que se invoquen rutinas apropiadas en la implementación de la JVM compatible con Jazelle. Los detalles no se publican, ya que todas las partes internas 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 la JVM. Para los códigos de bytes no controlados (o si el sistema operativo los anula), el hardware invocará la JVM de software. El sistema está diseñado de modo que la JVM de software no necesite saber qué códigos de bytes están implementados en el hardware y la JVM de software proporcione una alternativa de software para el conjunto completo de códigos de bytes.
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 contengan código de software para ejecutar la instrucción BXJ y permitir el uso de la extensión de la arquitectura Jazelle de ARM sin [..] el consentimiento de ARM está expresamente prohibida". [6]
Los empleados de ARM han publicado en el pasado varios documentos técnicos que ofrecen algunos buenos consejos sobre la extensión del procesador. [ cita requerida ] Las versiones del Manual de referencia de arquitectura ARM disponibles a partir de 2008 han incluido pseudocódigo para la instrucción "BXJ" (Branch and eXchange to Java), pero los detalles más finos se muestran como "SUB-ARQUITECTURA DEFINIDA" y se documentan en otra parte.
El estado de Jazelle depende de una convención de llamadas acordada entre la JVM y el estado de hardware de Jazelle. Esta interfaz binaria de aplicación no está publicada por ARM, lo que convierte a Jazelle en una característica no documentada para la mayoría de los usuarios y las JVM de software libre.
Todo el estado de la máquina virtual se almacena en registros ARM normales, lo que permite la compatibilidad con sistemas operativos existentes y controladores de interrupciones sin modificaciones. Al reiniciar un código de bytes (por ejemplo, después de un retorno de una interrupción), se volverá a ejecutar la secuencia completa de instrucciones ARM relacionadas.
Se designan registros específicos para contener las partes más importantes del estado de la JVM: los registros R0–R3 contienen un alias de la parte superior de la pila de Java, R4 contiene el operando local cero de Java (puntero a *this) y R6 contiene el puntero de la pila de Java. [7]
Jazelle reutiliza el contador de programa existente PC o su registro sinónimo R15. Un puntero al siguiente bytecode va en R14, [8] por lo que el uso del PC no suele ser visible para el usuario excepto durante la depuración.
El bytecode de Java se indica como el conjunto de instrucciones actual mediante una combinación de dos bits en el CPSR (registro de estado del programa actual) del ARM. El bit "T" debe estar borrado y el bit "J" configurado. [9]
Los códigos de bytes son decodificados por el hardware en dos etapas (en comparación con 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 aproximadamente 4 ciclos de reloj. [10]
Para que la entrada al estado de hardware de Jazelle sea exitosa, el bit JE (Habilitación de Jazelle) [3] en el registro CP14:C0(C2)[bit 0] debe estar configurado; la limpieza del bit JE por un sistema operativo [privilegiado] proporciona una anulación de alto nivel para evitar que los programas de aplicación utilicen la aceleración de hardware de Jazelle. [11] Además, el bit CV (Configuración válida) [3] que se encuentra en CP14:c0(c1)[bit 1] [11] debe estar configurado para mostrar que hay una configuración de estado de Jazelle consistente para que el hardware la utilice.
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 ( Bifurcación ) estándar. [3] El único momento en el que un sistema operativo o un depurador deben ser plenamente conscientes del modo Jazelle es cuando decodifican una instrucción con fallas 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 bifurcación BXJ, ya que, independientemente del procesamiento de hardware o software, el sistema debe saber dónde comenzar a decodificar.
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 cambiar de tarea y se reinicia el procesamiento del código de bytes Java actual. [7]
Después de entrar en el modo de estado Jazelle, los códigos de bytes se pueden procesar de una de tres maneras: decodificados y ejecutados de forma nativa en hardware, manejados en software (con código JVM ARM/ThumbEE 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 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 bytecode no controlado o se produzca una excepción. Entre 134 y 149 bytecodes (de los 203 bytecodes especificados en la especificación JVM) se traducen y ejecutan directamente en el hardware.
Los registros de configuración de bajo nivel para la máquina virtual de hardware se almacenan en el coprocesador ARM "CP14 registro c0". Los registros permiten detectar, habilitar o deshabilitar el acelerador de hardware (si está disponible). [13]
Solo se requiere una implementación de hardware "trivial" de Jazelle (como la que se encuentra en el emulador QEMU ) para soportar el código de operación BXJ en sí (tratando a BXJ como una instrucción BX normal [3] ) y para devolver RAZ (lectura como cero) para todos los registros CP14:c0 relacionados con Jazelle. [14]
La arquitectura ARMv7 ha restado importancia a Jazelle y a la ejecución directa de bytecodes de JVM. En términos de implementación, ahora solo se requiere compatibilidad de hardware trivial con Jazelle: compatibilidad para ingresar y salir del modo Jazelle, pero no para ejecutar ningún bytecode de Java.
En su lugar, se prefería el entorno de ejecución Thumb ( ThumbEE ), pero desde entonces también quedó obsoleto. El soporte para ThumbEE era obligatorio en los procesadores ARMv7-A (como Cortex-A8 y Cortex-A9), y opcional en los procesadores ARMv7-R. ThumbEE apuntaba a entornos compilados, tal vez utilizando tecnologías JIT . No era en absoluto específico de Java y estaba completamente documentado; se esperaba 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. Integraba la comprobación de puntero nulo, definía algunos mecanismos de fallo nuevos y reutilizaba el espacio de código de operación LDM y STM de 16 bits para admitir algunas instrucciones, como la comprobación de rango, un nuevo esquema de invocación de controladores y más. En consecuencia, los compiladores que producían código Thumb o Thumb2 podían modificarse para que funcionaran con entornos de ejecución basados en ThumbEE.
{{cite web}}: CS1 maint: URL no apta ( enlace ){{cite web}}: CS1 maint: URL no apta ( enlace )