Cómo analizar fallos de máquinas virtuales J9 en IBM i
Caídas en código nativo relacionado con JNI
JNI es la abreviatura de Java Native Interface o JAVA Native Invocation. El estándar Java Native Interface (JNI), que ha sido parte de la plataforma Java desde Java 1.1, permite que el código Java interactúe con código escrito en otros lenguajes.
El código nativo utiliza JNI en diversas situaciones. Hay algunas cosas que se deben tener en cuenta al usar JNI (consulte Mejores prácticas para usar interfaces nativas de Java). El uso inadecuado de JNI por parte del código nativo a menudo provoca que los JOB J9 fallen. Algunas formas de utilizar JNI incluyen:
Métodos nativos de Java
Los métodos Java en IBM i se pueden implementar en otro lenguaje en un entorno ILE o PASE.
Uso de la API de Invocación
La API de Invocación es parte de JNI y se puede utilizar para integrar la Máquina Virtual Java (JVM) en aplicaciones locales, lo que permite a los programadores llamar a Java en código local. código. El código Java también se puede llamar desde otros lenguajes a través de la interfaz de funciones JNI.
Agente JVMTI
JVMTI (JVM Tool Interface) es una interfaz de programación local proporcionada por la máquina virtual Java. Es un componente de JVMPI (Java Virtual Machine Profiler Interface) y JVMDI (. Interfaz de depuración de máquina virtual Java)) versión actualizada. JVMTI proporciona interfaces de depuración y creación de perfiles y también admite monitoreo, análisis de subprocesos y análisis de cobertura. JVMTI proporciona un conjunto de interfaces de código nativo, por lo que usar JVMTI requiere tratar con C/C y JNI. El desarrollo de JVMTI generalmente se completa creando un Agente. El Agente utiliza funciones JVMTI, establece algunas funciones de devolución de llamada, obtiene la información del estado actual de la máquina virtual Java y, finalmente, puede manipular el estado de la máquina virtual. máquina. Después de compilar el Agente en una DLL, podemos cargarlo cuando se inicia el programa Java (modo de cargador de arranque) o, después de Java 5, usar la carga en tiempo de ejecución (modo de carga activa).
Caída dentro de J9
El propio J9 puede tener errores que provocan que la máquina virtual falle.
Otros fallos del código nativo no relacionados con J9
Después de la introducción de la máquina virtual Java en IBM i, muchos programas implementaron nuevas funcionalidades añadiendo código Java. La funcionalidad original todavía está implementada en código nativo. En estos códigos nativos (como el código C/C) puede haber acceso directo a la memoria y los accesos incorrectos al puntero pueden provocar que la JVM falle.
Bloqueo debido a sobrescritura de memoria
Además de causar potencialmente un fallo directo, los distintos tipos de código nativo descritos anteriormente pueden sobrescribir la memoria correcta al escribir en direcciones de memoria incorrectas, lo que provoca que se produzca un fallo. El código posterior que accede a estos datos incorrectos falla.
Recepción de señales de excepción
J9 tiene su propio procesador de señal instalado en su interior. Al recibir una señal específica como ABORT, J9 generará un volcado de núcleo y saldrá del TRABAJO actual.
Memoria local agotada
Actualmente, IBM i admite versiones de 32 o 64 bits de J9.
Para J9 de 32 bits, puede ejecutar la versión de 32 bits de J9. Para el J9 de 32 bits, debido a las limitaciones del modelo de direcciones, el J9 utiliza hasta 4 GB de memoria y la memoria local se almacena en este espacio de direcciones 4G. J9 normalmente genera la excepción java.lang.OutOfMemoryError cuando el montón de Java o la memoria local se quedan sin direcciones. Sin embargo, a veces una memoria local insuficiente puede provocar que un trabajo falle. Por ejemplo, al crear un hilo o llamar a otras API que requieren asignación de memoria local. Para J9 de 64 bits, el espacio de direcciones es 1 EB, por lo que el agotamiento del espacio de direcciones generalmente no es un problema. Sólo en casos excepcionales el sistema se quedará sin memoria física.