Renovación de servicio 5

Salida de la versión de Java™: La salida de las opciones de línea de mandatos java -version y java -showversion y la propiedad del sistema java.version se actualizan para contener el número de compilación de Oracle en el que se basa el SDK de IBM . Por ejemplo, la serie 1.8.0_141 indica que el SDK se basa en las bibliotecas de clases de Oracle SE 1.8, actualización 141 (U141).
La salida también contiene cambios para indicar la Versión, el Release, la Modificación, y el Número de fixpack (V.R.M.F). Por ejemplo, Java(TM) SE Runtime Environment (build 8.0.5.0 ... refleja la Versión 8, Renovación de servicio 5.

Gestión del almacenamiento dinámico de objetos Java cuando la JVM está desocupada (soloLinux® )

Las siguientes opciones de ajuste están disponibles para gestionar el almacenamiento dinámico de objetos Java cuando la JVM está desocupada:

La opción -XX:IdleTuningMinIdleWaitTime controla cuánto tiempo debe estar inactiva la JVM antes de que surtan efecto las demás opciones de ajuste.
La opción -XX:[+|-]IdleTuningCompactOnIdle controla si el recolector de basura debe recoger y compactar el montón de objetos Java, lo que mejora el uso del montón.
La opción -XX:[+|-]IdleTuningGcOnIdle controla si las páginas de memoria libres se liberan para reducir la huella de memoria.
La opción -XX:IdleTuningMinFreeHeapOnIdle se puede utilizar con -XX:+IdleTuningGcOnIdle para establecer la cantidad mínima de memoria libre que debe permanecer en el almacenamiento dinámico de objetos.
Esta opción sólo se aplica a las arquitecturas Linux en x86-32 y x86-64 cuando la política de recogida de basura Generational Concurrent (gencon) está en uso. Esta opción no es efectiva si el almacenamiento dinámico de objeto está configurado para utilizar páginas grandes.

Nueva modalidad de recogida de basura para tiempos de pausa reducidos

Hay disponible una nueva modalidad que funciona con la política de recogida de basura simultánea generacional (gencon). Cuando esta modalidad está habilitada, la JVM intenta reducir los tiempos de pausa de la recogida de basura para aplicaciones de almacenamiento dinámico grande y sensibles al tiempo de respuesta, lo que mejora la estabilidad del rendimiento. La modalidad está controlada por la opción -Xgc:concurrentScavenge , que requiere un mínimo de z/OS® V2R3 (o z/OS V2R2 con el APAR OA51643) y el hardware z14 , y solo está soportada para la JVM de 64 bits. Si no se cumple el requisito del sistema operativo ni de hardware, la opción se omitirá.

Capacidad del compilador JIT para asignar memoria superior a la barra de 2 GB (soloz/OS )

En sistemas z/OS V2R3 , la modalidad de residencia para programas de 64 bits (RMODE64) está habilitada de forma predeterminada. Esta característica permite a JIT asignar memorias caché de código ejecutable superiores a la barra de memoria de 2 GB. Este comportamiento es el predeterminado, a menos que la opción -Xjit:disableRMODE64 esté especificada en la línea de mandatos. Para obtener más información, consulte disableRMODE64 (soloz/OS ).

Ajuste de la memoria caché de clases compartidas

Ahora puede crear un límite flexible sobre el contenido de la memoria caché de clases compartidas que pueden consultarse y ajustarse mediante programación utilizando un MXBean o modificarse utilizando opciones de línea de mandatos. La posibilidad de supervisar y ajustar el tamaño de la memoria caché puede ayudarle a reducir el tiempo de ocupación y de inicio cuando se ejecutan varios servidores similares.

Si especifica la opción -Xscmx como en releases anteriores, no hay ningún cambio en el comportamiento; esta opción especifica el tamaño de una nueva memoria caché de clase compartida. Sin embargo, si también especifica la nueva opción -XX:SharedCacheHardLimit, la opción -Xscmx especifica el tamaño máximo flexible de la nueva memoria caché de clases compartidas y la opción -XX:SharedCacheHardLimit especifica el tamaño máximo real. Cuando se llegue al límite flexible máximo (la memoria caché es flexible completa), no se podrán añadir datos a la memoria caché a menos que aumente el límite flexible máximo. Para más información, consulte la opción -Xscmx y la opción-XX:SharedCacheHardLimit.

Compatibilidad mejorada de MXBean

Las extensiones de interfaz de supervisión y de gestión de las API java.lang.mangement están actualizadas para la compatibilidad mejorada con las clases com.sun.management siguientes.

GarbageCollectorMXBean
GarbageCollectionNotificationInfo
GcInfo
OperatingSystemMXBean
UnixOperatingSystemMXBean

Esta compatibilidad incluye la compatibilidad y la implementación de conversión de clases del conjunto completo de API proporcionadas por estas clases com.sun.management. Para obtener más información, consulte la publicación Language Management API Reference.

Si depende de la salida de las extensiones de interfaz anteriores, las siguientes opciones nuevas estarán disponibles para revertir al comportamiento de dicha implementación:

-Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns
-XX:[+|-]HeapManagementMXBeanCompatibility

Para obtener más información sobre estas opciones, consulte Cambio en el valor de retorno del método OperatingSystemMXBean.getProcessCpuTime() y Mejora de la supervisión de los grupos de memoria y de la actividad de recogida de basura.

Cambio en el valor de retorno del método OperatingSystemMXBean.getProcessCpuTime()

El método OperatingSystemMXBean.getProcessCpuTime() se ha cambiado para devolver valores en nanosegundos en lugar de cientos de nanosegundos, para la compatibilidad con com.sun.management.OperatingSystemMXBean y las interfaces de UnixOperatingSystemMXBean. Puede volver al comportamiento anterior utilizando la propiedad del sistema -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns opción .

Supervisión mejorada de las agrupaciones de memoria y de la actividad de recogida de basura

Para ayudarle a comprender el comportamiento de la aplicación, se han realizado mejoras en el recopilador de basura de IBM® y en los MXbeans de agrupación de memoria. En releases anteriores, la información de agrupación de memoria se agregaba y se notificaba para todo el almacenamiento dinámico de Java. En este release, se puede obtener información más detallada sobre las agrupaciones de memoria y la actividad del recopilador de basura para una política de recogida de basura.

Si la aplicación de supervisión está escrita para esperar sólo una agrupación de memoria de almacenamiento dinámico o se basa en el nombre de agrupación de memoria Java heap, puede volver a la implementación anterior utilizando la opción -XX:+HeapManagementMXBeanCompatibility. Para obtener más información sobre esta opción y los nuevos nombres ' MemoryPool ' y ' GarbageCollector ' que se proporcionan, consulte la opción -XX:[+|-]HeapManagementMXBeanCompatibility.

-XX:[+|-]InterleaveMemory inhabilitado de forma predeterminada (AIX®, Linuxy Windows)

La intercalación de memoria ahora está inhabilitada de forma predeterminada. Para obtener más información, consulte la opción -XX:[+|-]InterleaveMemory (AIX, Linux y Windows).

Los agentes de conexión tardía pueden redefinir o retransformar clases

Los agentes de conexión tardía pueden redefinir o retransformar clases de forma predeterminada. Ya no es necesario utilizar la opción -XX:+EnableHCR , que se describe en IBM SDK, Java Technology Edition, Versión 8: Información complementaria, para habilitar esta función. Para obtener más información sobre la API de conexión Java, consulte API de conexión Java en la documentación de usuario de OpenJ9 .

Información de diagnóstico mejorada para los enganches de la máquina virtual

Se añaden nuevos puntos de rastreo que se desencadenan cuando los retornos de llamada para un enganche de la máquina virtual, como por ejemplo el enganche de descarga de clases, supera un umbral de tiempo. Cuando se desencadena, se genera una sección nueva en la salida de volcado Java. Los puntos de rastreo y el volcado Java proporcionan información suficiente para identificar las devoluciones de llamada.

Para obtener más información sobre elHOOKde un archivo de volcado Java, consulte Hook (HOOK) en la documentación de usuario de OpenJ9. Para obtener más información sobre los puntos de rastreo, consulte Rastreo de aplicaciones Java en la publicación J9 VM reference.

Ya no es necesaria una página de memoria adicional cuando se utilizan tamaños de página grandes (sóloLinux on IBM Z y z/OS )

Ya no es necesarios permitir otra página de memoria al especificar un tamaño de almacenamiento dinámico que sea un múltiplo de un tamaño de página grande. En releases anteriores, si el tamaño de página era de 2 GB, por ejemplo, el valor -Xmx2G utilizaba realmente 4 GB de memoria. Para evitar utilizar más memoria, tenía que hacer que el tamaño del almacenamiento dinámico fuera algo menor que un número integral de páginas restando al menos 16 bytes. Por ejemplo, para un tamaño de página de 2 GB, tenía que especificar un tamaño de almacenamiento dinámico máximo de -Xmx2147483632 (2147483648 menos 16 bytes) en lugar de -Xmx2048m (2 GB). Para un tamaño de página de 4 GB, tenía que especificar un tamaño de almacenamiento dinámico de -Xmx4294967280 (4.294.967.296 menos 16 bytes) en lugar de -Xmx4096m (4 GB), etc. En este release, no tiene que reducir el tamaño del almacenamiento dinámico.

Valor predeterminado para el tamaño de almacenamiento dinámico de Java inicial

La opción -Xms establece el tamaño inicial del almacenamiento dinámico de Java. Si esta opción no está establecida en la línea de mandatos, el recopilador de basura establece un tamaño inicial de 8 MB de forma predeterminada. En releases anteriores del SDK, el recopilador de basura establece un valor predeterminado de 4 MB. Para obtener más información sobre este valor, consulte Opción -Xms en la documentación de usuario deOpenJ9.

Opción -Xthr:<fastNotify|noFastNotify>

Ahora puede utilizar -Xthr:fastNotify para aumentar el rendimiento de una aplicación, específicamente cuando el uso regular de wait y notify provoca que un gran número de hebras intenten adquirir un supervisor de Java. Para obtener más información, consulte Opción -Xthr en la documentación de usuario deOpenJ9.

Algunas subopciones de -Xzero ya no están soportadas

Las subopciones j9zip, noj9zip, sharezip y nosharezip ya no están soportadas. Si especifica estas opciones, se analizarán pero no harán nada. Para obtener más información sobre estas opciones, consulte Opción -Xms en la documentación de usuario deOpenJ9.

Las excepciones de la API de conexión empiezan ahora con com.sun

Las excepciones de la API de conexión ahora tienen como prefijo com.sun.tools.attach en lugar de com.ibm.tools.attach.

Recurso de instrumentación de tiempo de ejecución desactivado de forma predeterminada (soloAIX, Linuxy z/OS )

En actualizaciones anteriores, el recurso RI se habilitó de forma predeterminada en todas las plataformas que dan soporte al mismo. El recurso RI ahora está inhabilitado de forma predeterminada. Para más información, consulte -XX:[+|-]RuntimeInstrumentation en la documentación de usuarioOpenJ9.

Cambios en Strings para dar soporte a CompactStrings

Para soportar Strings compacto (-XX:+CompactStrings), java.lang.String ya no contiene un campo offset, que se utiliza para indicar el inicio de la String en los datos char[] subyacentes. El rendimiento puede verse afectado cuando se utilizan los métodos siguientes en el código para valores de beginIndex distintos de cero:

String.substring(int beginIndex)
String.substring(int beginIndex, int endIndex)

En releases anteriores, se crea una nueva String pero el char[] subyacente se comparte con la String original por lo que no se copian los datos char[]. Si el rendimiento se ha degradado significativamente porque ahora se están copiando los datos char[], intente volver a implementar el código para evitar la copia de los datos String.

Nota: Las aplicaciones que se escriben para ejecutarse en implementaciones Java que utilizan la máquina virtual HotSpot no se ven afectadas, porque los datos de String se copian, incluso cuando se utiliza un beginIndex de cero.

Tecnología de evaluación de objetos empaquetados eliminada

La vista previa de tecnología de objetos empaquetados ya no está disponible.

Renovación de servicio 5 fixpack 5

Este release contiene los últimos arreglos de IBM , la Oracle Critical Patch Update (CPU) de octubre de 2017 y las actualizaciones siguientes:

Cambios en la información de versión de Java

Se ha cambiado la salida del mandato java -version. A continuación se muestra un ejemplo:

java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 8.0.5.5 - pxa6480sr5fp5-20171109_02(SR5 FP5))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20171102_369060 (JIT enabled, AOT enabled)
OpenJ9 - 7ade437
OMR - 1b656cb
IBM - 59c3d96)
JCL - 20171109_01 based on Oracle jdk8u151-b12

La línea que empieza por OpenJ9 sustituye las líneas J9VM y JIT en la salida de renovaciones anteriores, ya que estos componentes ahora se aportan a Eclipse Foundation bajo el proyecto Eclipse OpenJ9.

Soporte de AIX

A partir de esta renovación y para todos los arreglos temporales futuros (ifixes), el nivel mínimo soportado de AIX 6.1 es ahora TL9. Si está en un nivel de mantenimiento inferior, el uso de determinadas extensiones de la API com.ibm.language.management puede dar como resultado las excepciones ProcessorUsageRetrievalException y GuestOSInfoRetrievalException .

Configuración del recuento de descriptores de archivos abiertos para el proceso Java

El número máximo de descriptores de archivos abiertos en un proceso lo controla el sistema operativo. En sistemas UNIX, configure este número estableciendo el límite fijo del sistema o ulimit.

Para evitar un uso excesivo de recursos durante el proceso de inicio, el SDK de IBM limita el número máximo de descriptores de archivo para un proceso Java a 64K. Se aplican las reglas siguientes:

Si el valor de ulimit es mayor que 64K, el recuento de descriptores de archivo toma como valor predeterminado 64K.
Si el valor ulimit es menor que 64K, el recuento de descriptores de archivo coincide con el valor ulimit.

Si la aplicación necesita un número mayor de descriptores de archivos abiertos o el rendimiento del arranque se ve afectado por el límite predeterminado establecido, puede configurar el valor estableciendo la siguiente variable de entorno:

export IBM_JAVA_FDLIMIT=file_descriptor_count

donde file_descriptor_count es un valor que es menor que ulimit de su sistema.

Renovación de servicio 5 fixpack 10

Este release contiene los últimos arreglos de IBM y las Critical Patch Updates (CPU) de Oracle de enero de 2018.

Comprobación de seguridad

Para la máquina virtual Eclipse OpenJ9 , para mejorar la seguridad, las comprobaciones de seguridad en las API siguientes están ahora habilitadas de forma predeterminada, cuando SecurityManger está habilitado:

com.ibm.jvm.Dump.JavaDump()
com.ibm.jvm.Dump.HeapDump()
com.ibm.jvm.Dump.SnapDump()
com.ibm.jvm.Log.QueryOptions()
com.ibm.jvm.Log.SetOptions(String)
com.ibm.jvm.Trace.set(String)
com.ibm.jvm.Trace.snap()
com.ibm.jvm.Trace.suspend()
com.ibm.jvm.Trace.suspendThis()
com.ibm.jvm.Trace.resume()
com.ibm.jvm.Trace.resumeThis()
com.ibm.jvm.Trace.registerApplication(String, String[])
com.ibm.jvm.Trace.trace(<any parameters>)

Puede inhabilitar la comprobación de seguridad para estas API estableciendo las siguientes propiedades del sistema en la línea de mandatos:

-Dcom.ibm.jvm.enableLegacyTraceSecurity=false
-Dcom.ibm.jvm.enableLegacyDumpSecurity=false
-Dcom.ibm.jvm.enableLegacyLogSecurity=false

Renovación de servicio 5 fixpack 15

Este release contiene los siguientes cambios, además de los últimos arreglos de IBM y la Oracle Critical Patch Update (CPU) de abril de 2018:

Comprobación de seguridad

Si se utiliza un SecurityManager con la compartición de datos de clases y la aplicación en ejecución llama a las API com.ibm.oti.shared.SharedClassUtilities getSharedCacheInfo() o destroySharedCache(), debe conceder al código que llama a las API el SharedClassesNamedPermission adecuado. Para obtener un código de ejemplo, consulte Soporte para cargadores de clases personalizados en la documentación de usuario de OpenJ9 .

Nuevo MXBean para controlar el procesamiento de volcado

La producción de datos de diagnóstico de volcado y rastreo se puede controlar mediante las opciones de línea de mandatos -Xdump durante el inicio. Si desea cambiar la configuración de volcado, debe reiniciar la aplicación. Para evitar el reinicio, puede utilizar la interfaz de proceso de aplicaciones (API) com.ibm.jvm.Dump para cambiar dinámicamente la configuración. Ahora hay disponible un nuevo MXBean que llama a los métodos de la API de volcado para que pueda configurar dinámicamente el volcado mientras supervisa de forma remota una aplicación que se está ejecutando en un servidor o contenedor remoto.

Para obtener más información sobre las opciones de configuración, consulte la documentación de la API.

Soporte de hardware

La compatibilidad con IBM POWER9 se añadió en esta actualización, pero desde entonces se han realizado importantes correcciones, incluidas las de seguridad. Si utiliza IBM POWER9, debe actualizar al menos al fixpack 30.

Soporte de sistema operativo

Ahora se da soporte a los siguientes sistemas operativos:

Red Hat® Enterprise Linux (RHEL) 7.5
Ubuntu 18.04

El modo de recuperación concurrente ya es compatible con Linux on IBM Z

La opción -Xgc:concurrentScavenge ahora está soportada en el hardware IBM z14 con RHEL 7.5 y Ubuntu 18.04 en los siguientes niveles y configuraciones:

Sistemas operativos

RHEL 7.5 (nivel de kernel mínimo 4.14)
Ubuntu 18.04

Hipervisores

Las soluciones KVM con QEMU 2.10 o versiones posteriores y un nivel de kernel de host mínimo 4.12

Nueva variable de entorno para conmutar entre conversores ICONV y Java en z/OS

De forma predeterminada, el programa de utilidad ICONV se utiliza para convertir caracteres de un conjunto de páginas de códigos a otro. No obstante, en algunas instancias ICONV se convierte en un carácter que no se reconoce en determinadas plataformas. Por ejemplo, ICONV convierte el código EBCDIC x'25' (salto de línea) a Unicode '\u0085' (línea siguiente), lo que causa problemas a los analizadores XML.

La variable de entorno siguiente se puede establecer para seleccionar el conversor Java:

USE_JAVA_CONV=1

De forma predeterminada, la variable de entorno se establece en USE_JAVA_CONV=0, que utiliza el programa de utilidad ICONV.

Renovación de servicio 5 fixpack 16

El fixpack 16 incluye las siguientes características nuevas en la máquina virtual Eclipse OpenJ9:

iSoporte ampliado para la característica de ajuste de inactividad

La característica de ajuste inactiva en la máquina virtual OpenJ9 de Eclipse mantiene su huella de memoria pequeña liberando la memoria no utilizada de nuevo al sistema operativo. Esta característica está ahora disponible en Linux para IBM POWER ® e IBM Z® además de las arquitecturas x86 cuando se utiliza con la política de recogida de basura simultánea generacional (gencon). Para obtener más información sobre esta característica, consulte las siguientes opciones de línea de mandatos (en la documentación de usuario deOpenJ9), que controlan este comportamiento:

Cambiar al tamaño máximo de almacenamiento dinámico de Java predeterminado para las aplicaciones que se ejecutan en un contenedor

Cuando se utiliza la tecnología de contenedor, las aplicaciones normalmente se ejecutan por su cuenta y no necesitan competir por la memoria. En esta actualización, se introducen cambios para detectar cuándo se ejecuta la VM OpenJ9 dentro de un contenedor. Si la aplicación se ejecuta en un contenedor y desea que la máquina virtual asigne una fracción mayor de memoria al almacenamiento dinámico de Java, ahora puede establecer la opción -XX:+UseContainerSupport en la línea de mandatos para obtener un porcentaje mayor de memoria disponible. El porcentaje asignado depende del límite de memoria del contenedor. Para obtener más información, consulte -XX:[+|-]UseContainerSupport en la documentación de usuario deOpenJ9.

Renovación de servicio 5 fixpack 17

El fixpack 17 incluye las siguientes características nuevas en la máquina virtual Eclipse OpenJ9:

Nueva política de recogida de basura

Se introduce una nueva política en la máquina virtual de Eclipse OpenJ9 que expande el almacenamiento dinámico de Java de la forma normal, pero no reclama memoria mediante operaciones de recogida de basura. Esta modalidad es útil para aplicaciones de corta duración en las que no hay memoria suficiente para satisfacer los requisitos de tiempo de ejecución. Para obtener más información, consulte -Xgcpolicy:nogc en la documentación de usuario deOpenJ9.

Especificación del tamaño máximo de almacenamiento dinámico de Java como un valor de porcentaje

La VM OpenJ9 ahora da soporte al establecimiento del tamaño de almacenamiento dinámico como un porcentaje de la memoria física. Se reconocen las siguientes opciones de Oracle HotSpot y se pueden definir para la VM:

-XX:InitialRAMPercentage ( documentación del usuario OpenJ9 )
-XX:MaxRAMPercentage ( documentación del usuario OpenJ9 )

Si la aplicación se está ejecutando en un contenedor y ha especificado -XX:+UseContainerSupport, tanto el tamaño de almacenamiento dinámico predeterminado para los contenedores como los valores para estas nuevas opciones se basan en la memoria de contenedor disponible.

Soporte de clases compartidas para archivos jar anidados

Los cambios se realizan en la interfaz de programación de aplicaciones com.ibm.oti.shared para dar soporte a archivos jar anidados.

Renovación de servicio 5 fixpack 20

Este release contiene los últimos arreglos de IBM y Oracle Critical Patch Update (CPU) de julio de 2018.

Renovación de servicio 5 fixpack 25

Este release contiene los últimos arreglos de IBM y la Oracle Critical Patch Update (CPU) de octubre de 2018.

La documentación para dar soporte a IBM SDK, Java Technology Edition Versión 8 se ha modificado en esta renovación. Además de esta guía del SDK y la referencia de soporte de J9 VM, la documentación IBM ahora contiene la documentación del usuario Eclipse OpenJ9 VM. Se ha eliminado elimina algún material que se ha encontrado anteriormente en la referencia de la máquina virtual J9 para evitar la duplicación. La redirección está en vigor para minimizar el impacto de este cambio.

Para ver los cambios nuevos en la máquina virtual Eclipse OpenJ9 , consulte las siguientes notas del release en la documentación de usuario deOpenJ9:

Versión 0.10.0

Renovación de servicio 5 fixpack 26

El fixpack 26 incluye las siguientes características nuevas en la máquina virtual Eclipse OpenJ9:

Subopciones de compartición de datos de clase nueva

La opción -Xshareclasses:bootClassesOnly inhabilita el almacenamiento en memoria caché de clases cargadas por cargadores de clases que no sean de la rutina de carga. Esta subopción también habilita la subopción nonfatal, que permite que la VM se inicie incluso si se ha producido un error al crear la memoria caché de clases compartidas.

La opción -Xshareclasses:fatal evita que la VM se inicie si se ha producido un error al crear la memoria caché de clases compartidas. Es posible que desee habilitar esta subopción cuando utilice la subopción -Xshareclasses:bootClassesOnly para resolver problemas al crear la memoria caché.

El reconocimiento de contenedor en la máquina virtual OpenJ9 ahora está habilitado de forma predeterminada

Cuando se utiliza la tecnología de contenedor, las aplicaciones normalmente se ejecutan por su cuenta y no necesitan competir por la memoria. Si la máquina virtual detecta que se está ejecutando en un entorno de contenedor y se establece un límite de memoria para el contenedor, la máquina virtual ajusta automáticamente el tamaño de almacenamiento dinámico Java predeterminado máximo.

En releases anteriores, este comportamiento se habilitaba estableciendo la opción -XX:+UseContainerSupport. Este valor es ahora el valor predeterminado.

La modalidad de recogida de basura sin pausa ahora está disponible en plataformas Linux x86

La modalidad de recogida de basura sin pausas está dirigida a las aplicaciones sensibles al almacenamiento dinámico grande, a las aplicaciones sensibles al tiempo de respuesta. Cuando está habilitada, la máquina virtual intenta reducir los tiempos de pausa de GC. En releases anteriores, la modalidad de recogida de basura sin pausa (-Xgc:concurrentScavenge) solo estaba disponible en el hardware IBM z14 . Esta modalidad ahora está disponible en plataformas x86 Linux de 64 bits.

Nota: Se debe utilizar la política de recogida de basura simultánea generacional (gencon). Esta es la política predeterminada.

Ahora puede restringir los códigos hash de identidad a valores no negativos

OpenJ9 permite que los códigos de hashcodes de identidad tanto positivos como negativos, que pueden ser problemáticos si su programa (incorrecto) asume que los códigos hash sólo pueden ser positivos. Sin embargo, ahora puede utilizar la opción -XX:+PositiveIdentityHash para limitar los códigos hash de identidad a valores no negativos. Debido a que la limitación de códigos hash de identidad a valores no negativos puede tener un impacto en el rendimiento de las operaciones con uso intensivo de hash, esta opción no está habilitada de forma predeterminada.

Soporte para opciones de OpenJDK HotSpot

Por motivos de compatibilidad, OpenJ9 admite las siguientes opciones de OpenJDK Hotspot:

-XX:MaxHeapSize, que es equivalente a la opción -Xmx.
-XX:InitialHeapSize, que es equivalente a la opción -Xms.

IBM_JAVA_OPTIONS está en desuso

La variable de entorno IBM_JAVA_OPTIONS está en desuso. En su lugar, utilice la nueva variable de entorno OPENJ9_JAVA_OPTIONS.

Renovación de servicio 5 fixpack 27

El fixpack 27 incluye las siguientes características nuevas en la máquina virtual Eclipse OpenJ9:

Flexibilidad mejorada para gestionar el tamaño de la memoria caché de código JIT: La memoria caché de código JIT almacena el código nativo de los métodos Java compilados. De forma predeterminada, el tamaño de la memoria caché de código es de 256 MB para una VM de 64 bits y de 64 MB para una VM de 31/32 bits. En releases anteriores, el tamaño de la memoria caché de código podría aumentarse a partir del valor predeterminado utilizando la opción de línea de mandatos -Xcodecachetotal . En este release, el tamaño también se puede reducir utilizando esta opción, con un tamaño mínimo de 2 MB. El tamaño de la memoria caché de datos de JIT, que conserva metadatos sobre métodos compilados. Si utiliza la opción -Xcodecachetotal para gestionar el tamaño de la memoria caché de código, el tamaño de la memoria caché de datos se ajusta en la misma proporción.

Renovación de servicio 5 fixpack 30

El fixpack 30 incluye las siguientes características nuevas en la máquina virtual Eclipse OpenJ9:

Soporte mejorado para la recogida de basura sin pausas

Ahora se da soporte a la modalidad de barrido simultáneo (-Xgc:concurrentScavenge) en sistemas operativos Windows de 64 bits.

El ajuste de inactividad está habilitado de forma predeterminada cuando la VM se ejecuta en un contenedor de docker

En un release anterior, se introdujo un conjunto de opciones de ajuste desocupado para gestionar la ocupación del almacenamiento dinámico de Java cuando la máquina virtual OpenJ9 está en estado desocupado. Las dos opciones siguientes ahora están habilitadas de forma predeterminada cuando la VM de OpenJ9 detecta que se está ejecutando en un contenedor y que la VM ha entrado en estado de inactividad:

-XX:[+|-]IdleTuningGcOnIdle, que ejecuta un ciclo de recogida de basura y libera las páginas de memoria libres al sistema operativo.
-XX:[+|-]IdleTuningCompactOnIdle, que compacta el almacenamiento dinámico de objetos para reducir la fragmentación.

De forma predeterminada, la VM se comprueba cada 180 segundos para detectar un estado desocupado. To control the wait time between checks, use the -XX:[+|-]IdleTuningMinIdleWaitTime option ( documentación del usuario OpenJ9 ). Para desactivar la detección de inactividad, establezca el valor en 0.

Cambios en los permisos de directorio de memoria caché de clases compartidas predeterminadas (no Windows)

Si no utiliza la subopción cachDirPerm para especificar permisos para un directorio de memoria caché de clases compartidas, y el directorio de memoria caché no es el valor predeterminado de /tmp/javasharedresources, se aplican los cambios siguientes:

Al crear un nuevo directorio de memoria caché, los permisos predeterminados son ahora más estrictos.
Si el directorio de memoria caché ya existe, los permisos ahora no cambian (anteriormente, cuando se abría una memoria caché utilizando este directorio, los permisos se establecerían en 0777).

Para obtener más información, consulte -Xshareclasses en la documentación de usuario deOpenJ9.

Renovación de servicio 5 fixpack 31

El fixpack 31 incluye las siguientes características nuevas en la máquina virtual Eclipse OpenJ9, tal como se describe en la documentación del usuario de OpenJ9:

Mejor información de diagnóstico para sistemas Linux que implementan grupos de control

Si utiliza grupos de control (cgroups) para gestionar recursos en sistemas Linux , la información sobre los límites de CPU y memoria se registra ahora en un archivo de volcado Java. Esta información es especialmente importante para las aplicaciones que se ejecutan en contenedores de Docker, porque cuando los límites de recursos se establecen dentro de un contenedor, el motor de Docker se basa en los grupos para aplicar los valores. Si obtiene un error Java OutOfMemoryError porque se ha establecido un límite de contenedor en la cantidad de memoria disponible para una aplicación y esta asignación no es suficiente, puede diagnosticar este problema a partir del archivo de volcado de Java. Puede encontrar la información de cgroup en la sección ENVINFO.

Grabación de un volcado Java en STDOUT o STDERR

Ahora puede escribir un archivo de volcado Java en STDOUT o STDERR utilizando la opción de línea de mandatos -Xdump .

Soporte mejorado para la recogida de basura sin pausas

La modalidad de recogida de basura simultánea ahora está soportada en las plataformas siguientes:

Linux en IBM POWER LE
AIX

Renovación de servicio 5 fixpack 35

El fixpack 35 incluye las actualizaciones siguientes:

Soporte para la nueva era japonesa: El soporte se añade para el nuevo nombre de la era, Reiwa. Para obtener más información sobre los cambios, consulte Cambios de la era japonesa para IBM SDK, Java Technology Edition.
Soporte para más versiones del sistema operativo: Se ha añadido soporte para Red Hat Enterprise Linux (RHEL) versión 8 y Windows Server 2019. Para obtener listas de sistemas operativos soportados, consulte Entornos soportados.
Cambio al tamaño de pila nativa predeterminado en z/OS de 64 bits: El tamaño de pila predeterminado para las hebras del sistema operativo en z/OS de 64 bits se cambia de 384 KB al mínimo del sistema operativo de 1 MB. Para obtener más información sobre este valor, consulte -Xmso.

El fixpack 35 incluye las siguientes características nuevas en la máquina virtual Eclipse OpenJ9, tal como se describe en la documentación de usuario de OpenJ9:

Nueva opción para ignorar o informar de opciones -XX no reconocidas: opciones: De forma predeterminada, se ignoran las opciones de línea de mandatos de -XX: no reconocidas, lo que evita que se produzca un error de inicio de aplicación. Ahora puede utilizar -XX:-IgnoreUnrecognizedXXColonOptions para desactivar este comportamiento, de modo que en su lugar se informe de las opciones -XX: no reconocidas. Para obtener más información, consulte -XX:[+|-]IgnoreUnrecognizedXXColonOptions en la documentación de usuarioOpenJ9.
Grabación de un volcado Java en STDOUT o STDERR: Ahora puede escribir un archivo de volcado Java en STDOUT o STDERR utilizando la opción de línea de mandatos -Xdump . Consulte Escritura en STDOUT/STDERR en la documentación de usuario deOpenJ9 para obtener más detalles.
Mejor información de diagnóstico para sistemas Linux que implementan grupos de control: Si utiliza grupos de control (cgroups) para gestionar recursos en sistemas Linux , la información sobre los límites de CPU y memoria se registra ahora en un archivo de volcado Java. Esta información es especialmente importante para las aplicaciones que se ejecutan en contenedores de Docker, porque cuando los límites de recursos se establecen dentro de un contenedor, el motor de Docker se basa en los grupos para aplicar los valores. Si obtiene un error Java OutOfMemoryError porque se ha establecido un límite de contenedor en la cantidad de memoria disponible para una aplicación y esta asignación no es suficiente, puede diagnosticar este problema desde el archivo de volcado Java. Puede encontrar la información de cgroup en la sección ENVINFO. Para obtener una salida de ejemplo, consulte Volcado de Java (ENVINFO) en la documentación de usuario deOpenJ9.
Soporte mejorado para la recogida de basura sin pausas: Ahora se da soporte a la modalidad de barrido simultáneo (-Xgc:concurrentScavenge) en AIX y Linux en POWER.
Nueva opción OpenJ9 para impedir que se utilice una consulta de red para determinar el nombre de host y la dirección IP.: De forma predeterminada, se utiliza una consulta de red para determinar el nombre de host y la dirección IP para la resolución de problemas. Para evitar que el programa esté en espera de tiempo de espera si no se puede establecer contacto con un servidor de nombres, ahora puede evitar que se lleve a cabo la consulta. Para más información, consulte -XX:[+|-]ReadIPInfoForRAS en la documentación de usuarioOpenJ9.
Nueva opción experimental para mejorar el rendimiento de los campos observados por JVMTI: En esta versión se introduce la opción " -XX:[+|-]JITInlineWatches " ( documentación del usuario OpenJ9 ). Cuando está habilitada, la opción se activa en operaciones experimentales de JIT que están pensadas para mejorar el rendimiento de los campos observados por JVMTI. Esta opción sólo se admite actualmente en plataformas x86 (Windows, macOS, y Linux).
Cambio al tamaño de pila nativa predeterminado en z/OS de 64 bits: El tamaño de pila predeterminado para las hebras del sistema operativo en z/OS de 64 bits cambia de 384 KB a 1 MB. Para obtener más información sobre este valor, consulte -Xmso.

Renovación de servicio 5 fixpack 36

El fixpack 36 incluye las siguientes nuevas características y cambios en la máquina virtual Eclipse OpenJ9, tal como se describe en la documentación del usuario de OpenJ9:

Cambios en el número de generación de la memoria caché de clases compartidas: En todas las plataformas, se ha cambiado el formato de las clases que se almacenan en la memoria caché de clases compartidas, lo que hace que la JVM cree una nueva memoria caché de clases compartidas, en lugar de volver a crear o reutilizar una memoria caché existente. Para ahorrar espacio, puede eliminar todas las memorias caché existentes a menos que se estén utilizando en un release anterior.

Renovación de servicio 5 fixpack 37

El fixpack 37 incluye las siguientes nuevas características y cambios en la máquina virtual Eclipse OpenJ9, tal como se describe en la documentación del usuario de OpenJ9:

Mejora del soporte de la plataforma para la recogida de basura sin pausa: La compatibilidad con el modo de recuperación concurrente se amplía ahora a z/OS y Linux on IBM Z.
Soporte de Transparent HugePage: La máquina virtual ahora da soporte a la asignación de páginas grandes en Linux cuando se utiliza el valor madvise . Para habilitar esta característica, especifique la opción -XX:+TransparentHugePage en la línea de mandatos al iniciar la aplicación.
-XX:[ opción+|-]JITInlineWatches ' soportada en ' z/OS y ' Linux on IBM Z, y activada por defecto: Esta opción, introducida en un release anterior, activa las operaciones JIT experimentales que están pensadas para mejorar el rendimiento de los campos observados por JVMTI. La opción ya es compatible con z/OS y Linux on IBM Z, y está activada por defecto.
Soporte para opciones de OpenJDK HotSpot: La opción -XX:OnOutOfMemoryError OpenJDK Hotspot ahora está soportada para la compatibilidad.
Eliminación de la opción -Xdiagnosticscollector: Esta opción era redundante y se ha eliminado.

Renovación de servicio 5 fixpack 40

El fixpack 40 incluye las actualizaciones siguientes:

Implementación de JDWP sustituida por equivalente de OpenJDK

JDWP se utiliza para depurar aplicaciones Java, por ejemplo, tal como se menciona en Opciones estándar, y Java Virtual Machine Tool Interface en la documentación de OpenJ9 . La implementación anterior de JDWP ahora se sustituye por el equivalente de OpenJDK. Este cambio elimina un problema con la implementación anterior y aumenta la alineación con el software de código abierto. Puesto que estas dos implementaciones son diferentes, las opciones que están disponibles también son diferentes. Estas opciones ya no existen: version, src, logy trace. Estas opciones son nuevas: launch, onthrow, onuncaught, mutf8y quiet. Para obtener más información sobre las opciones para la nueva implementación de JDWP, consulte la ayuda de la línea de mandatos:

java -agentlib:jdwp=help

El fixpack 40 incluye las siguientes características nuevas en la máquina virtual Eclipse OpenJ9, tal como se describe en la documentación de usuario de OpenJ9:

Cómo establecer automáticamente un tamaño de almacenamiento dinámico inicial

La VM ahora puede aprender y establecer un tamaño de almacenamiento dinámico inicial adecuado para una aplicación como alternativa a un usuario que dimensione y establezca manualmente un valor -Xms. La VM registra el tamaño del almacenamiento dinámico cuando el proceso de inicio finaliza, escribiendo estos datos en la memoria caché de las clases compartidas. Un valor medio se establece en unos pocos reinicios, lo que ayuda a garantizar que el valor utilizado para el tamaño de almacenamiento dinámico inicial sea lo más preciso posible. El tamaño de almacenamiento dinámico registrado es específico de la línea de mandatos de la aplicación, por lo que se almacena una sugerencia distinta para cada línea de mandatos exclusiva.

Para activar este comportamiento, establezca la opción -XX:+UseGCStartupHints en la línea de mandatos al iniciar la aplicación.

Heurística para compactación durante recogida de basura inactiva

La VM ahora compacta automáticamente el almacenamiento dinámico cuando se cumplen determinados desencadenantes durante la recogida de basura desocupada. Como resultado de este cambio, la opción -XX:[+|-]IdleTuningCompactOnIdle queda obsoleta.

Cambio en el comportamiento de -XX:IdleTuningCompactOnIdle

La opción -XX:[+|-]IdleTuningCompactOnIdle ya no es efectiva cuando no se especifica la opción -XX:+IdleTuningGcOnIdle.

Cambios en la interfaz interna

Las interfaces internas de la API de conexión han cambiado un poco, lo que afecta a la biblioteca de clases interna del SDK y a los archivos tools.jar y healthcenter.jar.

Si una aplicación utiliza una copia privada del archivo tools.jar de un release anterior, es posible que la aplicación no pueda utilizar la API de conexión en este release porque las clases Java no coinciden. En su lugar, utilice el archivo tools.jar de este release.
Del mismo modo, el archivo healthcenter.jar de este release no es compatible con releases anteriores.

Renovación de servicio 5 fixpack 41

El fixpack 41 incluye las siguientes nuevas características y cambios en la máquina virtual Eclipse OpenJ9, tal como se describe en la documentación del usuario de OpenJ9:

El valor automático del tamaño de almacenamiento dinámico inicial está habilitado de forma predeterminada: La opción -XX:[+|-]UseGCStartupHints, que, cuando está habilitada, activa el aprendizaje automático y el establecimiento de un tamaño de almacenamiento dinámico adecuado para una aplicación, ahora está habilitada de forma predeterminada.
Opción para compartir clases anónimas de VM: En releases anteriores, las clases anónimas, las creadas por Unsafe.defineAnonymousClass, no se almacenaban en la memoria caché de clases compartidas. Estas clases ahora se almacenan allí de forma predeterminada, lo que significa que están disponibles para la compilación AOT (ahead-of-time), lo que potencialmente mejora el rendimiento del arranque. Se ha añadido una nueva opción, -XX:[+|-]ShareAnonymousClasses, que le permite detener las clases anónimas que se almacenan en la memoria caché de clases compartidas.
Mejoras de rendimiento para los campos de observación de JVMTI en Power Systems: La opción " -XX:[+|-]JITInlineWatches ", que activa las operaciones JIT para mejorar el rendimiento de los campos vigilados por JVMTI, ahora también es compatible con AIX y Linux on Power Systems.
Linux en x86: Soporte para páginas grandes transparentes (THP): Cuando se utiliza el valor madvise (/sys/kernel/mm/transparent_hugepage/enabled) en Linux en sistemas x86 , THP está ahora habilitado de forma predeterminada. Para inhabilitar esta característica, establezca -XX:-TransparentHugePage en la línea de mandatos al iniciar la aplicación. El valor THP en otros sistemas permanece inhabilitado de forma predeterminada cuando se utiliza madvise, pero se puede habilitar estableciendo -XX:+TransparentHugePage.
Cambios en el número de generación de la memoria caché de clases compartidas: El formato de las clases que se almacenan en la memoria caché de clases compartidas ha cambiado, lo que hace que la JVM cree una nueva memoria caché de clases compartidas en lugar de volver a crear o reutilizar una memoria caché existente. Para ahorrar espacio, puede eliminar todas las memorias caché compartidas existentes a menos que las esté utilizando un release anterior. Como resultado del cambio de formato, ahora aparece una columna de capa en la salida de la opción -Xshareclasses:listAllCaches. Este cambio es para dar soporte a una futura mejora.