Actualisation de service 5

Sortie de la version Java™: La sortie des options de ligne de commande java -version et java -showversion et de la propriété système java.version est mise à jour pour contenir le numéro de version Oracle sur lequel est basé le SDK IBM . Par exemple, la chaîne 1.8.0_141 signifie que le SDK est basé sur les bibliothèques de classes Oracle SE 1.8, mise à jour 141 (U141).
La sortie contient également des changements pour indiquer les numéros de Version, Edition, Modification et Groupe de correctifs (V.E.M.G). Par exemple, Java(TM) SE Runtime Environment (build 8.0.5.0 ... reflète la version 8, actualisation de service 5.

Gestion du segment de mémoire des objets Java lorsque la machine virtuelle Java est en veille (Linux® uniquement)

Les options d'optimisation suivantes sont disponibles pour gérer le segment de mémoire des objets Java lorsque la machine virtuelle Java est inactive:

L'option -XX:IdleTuningMinIdleWaitTime contrôle la durée d'inactivité de la JVM avant que les autres options de réglage ne prennent effet.
L'option -XX :[+|-]IdleTuningCompactOnIdle détermine si le ramasse-miettes doit collecter et compacter le tas d'objets Java, ce qui améliore l'utilisation du tas.
L'option -XX :[+|-]IdleTuningGcOnIdle détermine si les pages de mémoire libres sont libérées pour réduire l'empreinte mémoire.
L'option -XX:IdleTuningMinFreeHeapOnIdle peut être utilisée avec -XX:+IdleTuningGcOnIdle pour fixer la quantité minimum de mémoire libre qui doit subsister dans le tas d'objets.
Cette option s'applique uniquement aux architectures Linux sur x86-32 et x86-64 lorsque la politique de récupération de place Générationnelle Concurrent (gencon) est utilisée. Elle est sans effet si le tas d'objets est configuré pour utiliser de grandes pages.

Nouveau mode de récupération de place pour des temps de pause réduits

Un nouveau mode est disponible, qui fonctionne avec la politique de récupération de place générationnelle simultanée (gencon). Lorsque ce mode est activé, la JVM tente de réduire les temps de pause du récupérateur de place pour les applications particulièrement sensibles aux temps de réponse et fonctionnant avec un gros tas, ce qui améliore leur fluidité de fonctionnement. Le mode est contrôlé par l'option -Xgc:concurrentScavenge , qui requiert un minimum de matériel z/OS® V2R3 (ou z/OS V2R2 avec l'APAR OA51643) et z14 , et est pris en charge uniquement pour la machine virtuelle Java 64 bits. Si ces conditions de système d'exploitation et de matériel ne sont pas satisfaites, l'option est ignorée.

Possibilité pour le compilateur JIT d'allouer de la mémoire supérieure à la barre des 2 Go (z/OS uniquement)

Sur les systèmes z/OS V2R3 , le mode de résidence pour les programmes 64 bits (RMODE64) est activé par défaut. Il permet au JIT d'allouer des caches de code exécutable au-delà de la barre des 2 Go de mémoire. Ce comportement est appliqué par défaut, sauf si l'option -Xjit:disableRMODE64 est spécifiée sur la ligne de commande. Pour plus d'informations, voir disableRMODE64 (z/OS uniquement).

Réglage du cache de classes partagées

Vous pouvez maintenant appliquer une limite souple (soft) à la quantité de données que peut accueillir le cache des classes partagées. Cette limite peut être interrogée programmatiquement ou ajustée au moyen d'un MXBean, ou encore modifiée avec des options de ligne de commande. Ces capacités de surveillance et de réglage de la taille du cache peuvent vous aider à alléger l'empreinte mémoire de la JVM. En cas d'utilisation de plusieurs serveurs similaires, leurs JVM respectives peuvent aussi démarrer plus rapidement.

Si vous spécifiez l'option -Xscmx comme dans les éditions antérieures, le comportement ne change pas : cette option spécifie la taille d'un nouveau cache de classes partagées. En revanche, si vous spécifiez également la nouvelle option -XX:SharedCacheHardLimit, l'option -Xscmx fixe la limite de taille souple (soft) du nouveau cache de classes partagées, tandis que -XX:SharedCacheHardLimit en fixe la limite de taille réelle (limite dure). Lorsque la limite de taille souple est atteinte (on dit alors que le cache est plein à hauteur de la limite souple), plus aucune donnée ne peut être ajoutée au cache, à moins que vous ne repoussiez cette limite. Pour plus d'informations, voir l'option -Xscmx et l'option-XX:SharedCacheHardLimit.

Compatibilité MXBean améliorée

Les extensions d'interface de surveillance et de gestion des API java.lang.mangement ont été mises à jour pour améliorer la compatibilité avec les classes com.sun.management suivantes.

GarbageCollectorMXBean
GarbageCollectionNotificationInfo
GcInfo
OperatingSystemMXBean
UnixOperatingSystemMXBean

Cette compatibilité inclut la compatibilité de transtypage (cast) des classes et l'implémentation du jeu complet d'API fourni par ces classes com.sun.management. Pour plus d'informations, voir Language Management API Reference.

Si vous êtes tributaire de la sortie des anciennes extensions d'interface, les nouvelles options suivantes vous permettront de rétablir le comportement de cette implémentation :

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

Pour plus d'informations sur ces options, voir Modification de la valeur de retour de la méthode OperatingSystemMXBean.getProcessCpuTime( et Amélioration de la surveillance des pools de mémoire et de l'activité de ramassage des ordures.

Changement concernant la valeur de retour de la méthode OperatingSystemMXBean.getProcessCpuTime()

Pour des raisons de compatibilité avec les interfaces com.sun.management.OperatingSystemMXBean et UnixOperatingSystemMXBean, le fonctionnement de la méthode OperatingSystemMXBean.getProcessCpuTime() a été modifié afin que celle-ci renvoie désormais des valeurs en nanosecondes et non plus en centaines de nanosecondes. Vous pouvez rétablir le comportement précédent à l'aide de la propriété système Option -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns .

Surveillance améliorée des pools de mémoire et des activités de récupération de place

Pour vous aider à comprendre le comportement de votre application, des améliorations ont été apportées à IBM® Garbage Collector and Memory Pool MXbeans. Dans les éditions précédentes, les informations de pool de mémoire étaient agrégées et signalées pour l'ensemble du segment de mémoire Java. Dans cette édition, des informations plus détaillées peuvent être obtenues à propos des pools de mémoire et de l'activité des récupérateurs de place prenant part à une politique de récupération de place.

Si votre application de surveillance ne s'attend à "voir" qu'un seul pool de mémoire de tas ou si elle est écrite avec des références au nom de pool de mémoire Java heap, vous pouvez rétablir l'ancien comportement en utilisant l'option -XX:+HeapManagementMXBeanCompatibility. Pour plus d'informations sur cette option et les nouveaux noms 'MemoryPool et 'GarbageCollector fournis, voir l'option -XX :[+|-]HeapManagementMXBeanCompatibility.

-XX:[+|-]InterleaveMemory désactivé par défaut (AIX®, Linuxet Windows)

L'entrelacement de la mémoire est désormais désactivé par défaut. Pour plus d'informations, voir l'option -XX :[+|-]InterleaveMemory (AIX, Linux et Windows).

Les agents Late attach peuvent redéfinir ou retransformer les classes

Les agents Late attach peuvent redéfinir ou retransformer les classes, par défaut. Vous n'avez plus besoin d'utiliser l'option -XX:+EnableHCR , décrite dans IBM SDK, Java Technology Edition, Version 8: Informations supplémentaires, pour activer cette fonction. Pour plus d'informations sur l'API Java attach, voir Java Attach API dans la documentation utilisateur OpenJ9 .

Informations de diagnostic améliorées pour les points d'ancrage (hooks) de la MV

De nouveaux points de trace sont ajoutés, qui sont déclenchés lorsque les rappels d'un point d'ancrage de la MV, tel que le point de déchargement de classe, dépassent une limite de temps. Lorsqu'elle est déclenchée, une nouvelle section est générée dans la sortie du vidage Java. Les points de trace et le vidage Java fournissent suffisamment d'informations pour identifier les rappels.

Pour plus d'informations sur leHOOKd'un fichier de vidage Java, voir Hook (HOOK) dans la documentation utilisateurOpenJ9. Pour plus d'informations sur les points de trace, voir Tracing Java applications dans le document J9 VM reference.

Une page de mémoire supplémentaire n'est plus nécessaire lors de l'utilisation de pages de grande taille (Linux on IBM Z et z/OS uniquement)

Vous n'avez plus besoin de prévoir une page supplémentaire de mémoire lorsque vous spécifiez, pour le tas des objets, une taille multiple de la taille de grande page. Dans les éditions précédentes, si la taille de page était de 2 Go, par exemple, la spécification de -Xmx2G utilisait en fait 4 Go de mémoire. Pour éviter cette consommation inutile de mémoire, il fallait régler la taille du tas à une valeur légèrement plus petite qu'un nombre de pages entier en retranchant au moins 16 octets. Par exemple, pour une taille de page de 2 Go, il fallait spécifier une taille de tas maximale de -Xmx2147483632 (2147483648 moins 16 octets) au lieu de -Xmx2048m (2 Go). Pour une taille de page de 4 Go, il fallait spécifier une taille tas maximale de -Xmx4294967280 (4.294.967.296 moins 16 octets) au lieu de -Xmx4096m (4 Go), et ainsi de suite. A partir de cette édition, vous n'avez plus à réduire la taille du tas.

Valeur par défaut pour la taille de tas Java initiale

L'option -Xms définit la taille initiale du tas Java. Si cette option n'est pas spécifiée sur la ligne de commande, le récupérateur de place la fixe à 8 Mo, par défaut. Dans les éditions antérieures du SDK, il la fixait à 4 Mo, par défaut. Pour plus d'informations sur ce paramètre, voir -Xms option dans la documentation utilisateurOpenJ9.

Option -Xthr:<fastNotify|noFastNotify>

Vous pouvez désormais utiliser -Xthr:fastNotify pour accroître la vitesse de fonctionnement d'une application, en particulier lorsque l'usage régulier de wait et notify fait qu'un grand nombre d'unités d'exécution tentent d'acquérir un moniteur Java. Pour plus d'informations, voir -Xthr option dans la documentation utilisateurOpenJ9.

Certaines sous-options de -Xzero ne sont plus prises en charge

Les sous-options j9zip, noj9zip, sharezip et nosharezip ne sont plus prises en charge. Si vous spécifiez ces options, elles sont lues et interprétées, mais elles ne font rien. Pour plus d'informations sur ces options, voir Option -Xms dans la documentation utilisateur d'OpenJ9.

Les exceptions de l'API Attach commencent désormais par com.sun

Les exceptions de l'API Attach sont maintenant préfixées avec com.sun.tools.attach et non plus avec com.ibm.tools.attach.

Fonction d'instrumentation d'exécution désactivée par défaut (AIX, Linuxet z/OS uniquement)

Dans les mises à jour antérieures, la fonctionnalité RI était activée par défaut sur toutes les plateformes où elle était reconnue. Elle est désormais désactivée par défaut. Pour plus d'informations, voir -XX :[+|-]RuntimeInstrumentation dans la documentation utilisateur d'OpenJ9.

Changements dans Strings pour prendre en charge CompactStrings

Pour faciliter la compacité de Strings (-XX:+CompactStrings), java.lang.String ne contient plus de champ offset, qui est utilisé pour indiquer le début de String dans les données sous-jacentes de char[] . Les performances peuvent être affectées lors de l'utilisation des méthodes suivantes dans votre code pour les valeurs de beginIndex autres que zéro:

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

Dans les éditions précédentes, un nouveau fichier String est créé, mais le fichier char[] sous-jacent est partagé avec le fichier String d'origine de sorte qu'aucune donnée char[] n'est copiée. Si vous constatez une dégradation significative des performances du fait que les données char[] sont à présent copiées, essayez de réimplémenter le code de façon à éviter que les données du String ne soient copiées.

Remarque: les applications écrites pour s'exécuter sur des implémentations Java qui utilisent la machine virtuelle HotSpot ne sont pas affectées, car les données String sont copiées, même si vous utilisez un beginIndex égal à zéro.

Retrait de la technologie d'évaluation des objets condensés

L'aperçu technique des objets condensés n'est plus disponible.

Actualisation de service 5 groupe de correctifs 5

Cette édition contient les derniers correctifs IBM , la mise à jour CPU (Critical Patch Update) Oracle d'octobre 2017 et les mises à jour suivantes:

Modifications apportées aux informations de version Java

La sortie de la commande java -version comporte des changements. Par exemple :

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 ligne commençant par OpenJ9 remplace les lignes J9VM et JIT dans la sortie des actualisations plus anciennes, car ces composants sont désormais apportés sous forme de contribution à la Fondation Eclipse sous le Projet Eclipse OpenJ9.

Prise en charge d'AIX

A partir de cette actualisation et pour tous les futurs correctifs temporaires (ifixes), le niveau minimal pris en charge de AIX 6.1 est désormais TL9. Si vous êtes sur un niveau de maintenance plus bas, l'usage de certaines extensions de l'API com.ibm.language.management risque de se solder par des exceptions ProcessorUsageRetrievalException et GuestOSInfoRetrievalException.

Configuration du nombre de descripteurs de fichiers ouverts pour le processus Java

Le nombre maximum de descripteurs de fichiers ouverts dans un processus est contrôlé par le système d'exploitation. Sur les systèmes UNIX, vous configurez ce nombre en définissant la limite absolue du système ou ulimit.

Pour éviter une utilisation excessive des ressources lors du processus de démarrage, le SDK IBM limite le nombre maximal de descripteurs de fichier pour un processus Java à 64K. Les règles suivantes s'appliquent :

Si votre valeur ulimit est supérieure à 64K, le nombre de descripteurs de fichiers est ramené à la valeur par défaut de 64K.
Si votre valeur ulimit est inférieure à 64K, le nombre de descripteurs de fichiers est rendu identique à cette valeur.

Si votre application a besoin d'un plus grand nombre de descripteurs de fichiers ouverts ou si la limite appliquée par défaut dégrade les performances au démarrage, vous pouvez configurer la valeur souhaitée en l'affectant à la variable d'environnement suivante :

export IBM_JAVA_FDLIMIT=file_descriptor_count

où nombre_descripteurs_fichiers est une valeur inférieure à votre ulimit système.

Actualisation de service 5 groupe de correctifs 10

Cette édition contient les derniers correctifs IBM et la mise à jour CPU (Critical Patch Update) Oracle de janvier 2018.

Vérifications de sécurité

Pour la machine virtuelle Eclipse OpenJ9 , pour améliorer la sécurité, les contrôles de sécurité dans les API suivantes sont désormais activés par défaut, lorsque SecurityManger est activé:

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>)

Vous pouvez désactiver les contrôles de sécurité pour ces API en définissant les propriétés système suivantes sur la ligne de commande :

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

Actualisation de service 5 groupe de correctifs 15

Cette édition contient les modifications suivantes, en plus des derniers correctifs IBM et de la mise à jour CPU (Critical Patch Update) Oracle d'avril 2018:

Vérifications de sécurité

Si un SecurityManager est utilisé avec le partage des données des classes et que l'application exécutée appelle les API (méthodes) getSharedCacheInfo() ou destroySharedCache() de com.ibm.oti.shared.SharedClassUtilities, vous devez accorder l'autorisation SharedClassesNamedPermission appropriée au code qui appelle ces API. Pour obtenir un exemple de code, voir Prise en charge des chargeurs de classe personnalisés dans la documentation utilisateur d' OpenJ9 .

Nouveau MXBean pour contrôler le traitement des vidages

La production de données de diagnostic par vidage ou trace peut être contrôlée au démarrage par les options de ligne de commande -Xdump. Si vous voulez changer la configuration de vidage, cela vous oblige à redémarrer l'application. Pour éviter ça, vous pouvez utiliser l'API com.ibm.jvm.Dump afin de changer dynamiquement la configuration. Un nouveau MXBean est à présent disponible, qui appelle les méthodes de l'API Dump pour vous permettre de configurer dynamiquement le vidage tout en surveillant à distance une application qui s'exécute dans un serveur ou un conteneur distant.

Pour plus d'informations sur les options de configuration, voir la documentation de l'API.

Support matériel

La prise en charge d'IBM POWER9 a été ajoutée lors de cette mise à jour, mais d'importants correctifs, y compris des correctifs de sécurité, ont été apportés depuis. Si vous utilisez IBM POWER9, vous devez effectuer une mise à niveau vers au moins le groupe de correctifs 30.

Systèmes d'exploitation pris en charge

Les systèmes d'exploitation suivants sont désormais pris en charge :

Red Hat® Enterprise Linux (RHEL) 7.5
Ubuntu 18.04

Le mode de récupération simultanée est désormais pris en charge pour Linux on IBM Z

L'option -Xgc:concurrentScavenge est désormais prise en charge sur le matériel IBM z14 avec RHEL 7.5 et Ubuntu 18.04 aux niveaux et configurations suivants:

Systèmes d'exploitation

RHEL 7.5 (niveaux de noyau minimum 4.14)
Ubuntu 18.04

Hyperviseurs

Solutions KVM avec QEMU 2.10 ou version ultérieure et niveau minimum de noyau 4.12

Nouvelle variable d'environnement permettant de basculer entre les convertisseurs ICONV et Java sous z/OS

Par défaut, la conversion des caractères d'une page de codes vers une autre se fait au moyen de l'utilitaire ICONV. Il arrive cependant que celui-ci convertisse un caractère en un autre qui n'est pas reconnu sur certaines plateformes. Par exemple, ICONV convertit le code EBCDIC x'25' (saut de ligne) en Unicode '\u0085' (ligne suivante), ce qui est un problème pour les analyseurs syntaxiques XML.

La variable d'environnement suivante peut être définie pour sélectionner le convertisseur Java:

USE_JAVA_CONV=1

Par défaut, elle est réglée à 0 (USE_JAVA_CONV=0), et c'est alors l'utilitaire ICONV qui est utilisé comme convertisseur.

Actualisation de service 5 groupe de correctifs 16

Le Fix pack 16 inclut les nouvelles fonctionnalités suivantes dans la machine virtuelle Eclipse OpenJ9 :

Support étendu de la fonctionnalité d'optimisation à l'état de repos

Dans la MV Eclipse OpenJ9, la fonctionnalité IdleTuning (optimisation à l'état de repos) veille à ce que l'empreinte mémoire reste aussi petite que possible en libérant la mémoire inutilisée pour la rendre au système d'exploitation. Cette fonction est désormais disponible sur Linux pour IBM POWER ® et IBM Z® en plus des architectures x86 lorsqu'elle est utilisée avec la règle de récupération de place générationnelle simultanée (gencon). Pour plus d'informations sur cette fonction, voir les options de ligne de commande suivantes (dans la documentation utilisateurOpenJ9), qui contrôlent ce comportement:

Modification de la taille de segment de mémoire Java maximale par défaut pour les applications qui s'exécutent dans un conteneur

Avec la technologie des conteneurs, les applications fonctionnent généralement seules dans leur conteneur et n'ont pas besoin de concourir pour obtenir de la mémoire. Dans cette mise à jour, des changements ont été introduits afin de détecter les cas où la MV OpenJ9 fonctionne à l'intérieur d'un conteneur. Si votre application s'exécute dans un conteneur et que vous souhaitez que la machine virtuelle alloue une plus grande partie de la mémoire au segment de mémoire Java, vous pouvez désormais définir l'option -XX:+UseContainerSupport sur la ligne de commande pour obtenir un pourcentage de mémoire disponible plus élevé. Le pourcentage alloué dépend de la limite de mémoire du conteneur. Pour plus d'informations, voir -XX :[+|-]UseContainerSupport dans la documentation utilisateur d'OpenJ9.

Actualisation de service 5 groupe de correctifs 17

Le Fix pack 17 inclut les nouvelles fonctionnalités suivantes dans la machine virtuelle Eclipse OpenJ9 :

Nouvelle politique de récupération de place

Une nouvelle politique est introduite dans la machine virtuelle Eclipse OpenJ9 qui étend le segment de mémoire Java de manière normale, mais ne permet pas de récupérer de la mémoire via des opérations de récupération de place. Ce mode est utile aux applications à courte durée de vie, lorsqu'il y a une quantité de mémoire suffisante pour satisfaire les besoins de l'exécution (runtime). Pour plus d'informations, voir -Xgcpolicy:nogc dans la documentation utilisateurOpenJ9.

Définition de la taille de segment de mémoire Java maximale en tant que valeur de pourcentage

Avec la MV OpenJ9, il est désormais possible de fixer la taille du tas en pourcentage de la mémoire physique. Les options suivantes d'Oracle HotSpot sont reconnues et peuvent être appliquées à la MV :

-XX:InitialRAMPercentage ( documentation de l'utilisateur OpenJ9 )
-XX:MaxRAMPercentage ( documentation de l'utilisateur OpenJ9 )

Si votre application s'exécute dans un conteneur et que vous avez spécifié l'option -XX:+UseContainerSupport, tant la taille de tas par défaut des conteneurs que les valeurs de ces nouvelles options seront basées sur la mémoire de conteneur disponible.

Support des classes partagées pour les fichiers jar imbriqués

Des changements ont été apportés à l'API com.ibm.oti.shared afin de rendre possible l'utilisation de fichiers jar imbriqués.

Actualisation de service 5 groupe de correctifs 20

Cette édition contient les derniers correctifs IBM et la mise à jour CPU (Critical Patch Update) Oracle de juillet 2018.

Actualisation de service 5 groupe de correctifs 25

Cette édition contient les derniers correctifs IBM et la mise à jour CPU (Critical Patch Update) Oracle d'octobre 2018.

La documentation de prise en charge de IBM SDK, Java Technology Edition version 8 a été modifiée dans cette actualisation. En plus de ce guide SDK et de la référence J9 VM, IBM Documentation contient désormais la documentation utilisateur Eclipse OpenJ9 VM. Certains contenus figurant auparavant dans la documentation de référence de la MV J9 ont été retirés afin d'éviter leur duplication. Une redirection a été mise en place pour minimiser l'impact de ce changement.

Pour toute nouvelle modification apportée à la machine virtuelle Eclipse OpenJ9 , consultez les notes sur l'édition suivantes dans la documentation utilisateurOpenJ9:

Version 0.10.0

Actualisation de service 5 groupe de correctifs 26

Le Fix pack 26 inclut les nouvelles fonctionnalités suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Nouvelle sous-option pour le partage des données de classes

L'option -Xshareclasses:bootClassesOnly désactive la mise en cache des classes chargées par les chargeurs de classes autres que d'amorçage. Cette sous-option active également la sous-option nonfatal, qui permet à la MV de démarrer même s'il y a eu une erreur à la création du cache de classes partagées.

L'option -Xshareclasses:fatal empêche la MV de démarrer s'il y a eu une erreur à la création du cache de classes partagées. Pour diagnostiquer les problèmes à la création du cache, vous pouvez activer cette sous-option lorsque la sous-option -Xshareclasses:bootClassesOnly est utilisée.

La découverte du conteneur (Container Awareness) dans la MV OpenJ9 est maintenant active par défaut

Avec la technologie des conteneurs, les applications fonctionnent généralement seules dans leur conteneur et n'ont pas besoin de concourir pour obtenir de la mémoire. Si la machine virtuelle détecte qu'elle s'exécute dans un environnement de conteneur et qu'une limite de mémoire est définie pour le conteneur, elle ajuste automatiquement la taille de segment de mémoire Java maximale par défaut.

Dans les anciennes versions, pour activer ce comportement, il fallait le demander explicitement en utilisant l'option -XX:+UseContainerSupport. Ce réglage est désormais en vigueur par défaut.

Le mode de récupération de place sans pause est désormais disponible sur les plateformes Linux x86

Le mode de récupération de place sans pause est destiné aux applications à grand tas sensibles aux temps de réponse. Lorsqu'il est en vigueur, la MV tente de réduire les temps de pause du récupérateur de place. Dans les éditions précédentes, le mode de récupération de place sans pause (-Xgc:concurrentScavenge) était disponible uniquement sur le matériel IBM z14 . Ce mode est désormais disponible sur les plateformes x86 Linux 64 bits.

Remarque: La politique de récupération de place générationnelle simultanée (gencon) doit être utilisée. (Il s'agit de la politique par défaut.)

Vous pouvez maintenant restreindre les codes de hachage identité aux valeurs non négatives

OpenJ9 autorise les codes de hachage identité positifs et négatifs, ce qui peut être problématique si votre programme considère (à tort) que les codes de hachage ne peuvent être que positifs. Cependant, grâce à l'option -XX:+PositiveIdentityHash, vous pouvez maintenant limiter les codes de hachage identité aux valeurs non négatives. Cette option n'est pas activée par défaut, car le fait de limiter les codes de hachage identité aux valeurs non négatives peut avoir un impact sur les performances des opérations faisant un usage intensif de la fonction de hachage.

Support des options de l'OpenJDK HotSpot

Pour des raisons de compatibilité, les options suivantes de l'OpenJDK Hotspot sont désormais supportées par OpenJ9 :

-XX:MaxHeapSize, qui équivaut à l'option -Xmx.
-XX:InitialHeapSize, qui équivaut à l'option -Xms.

IBM_JAVA_OPTIONS est dépréciée

La variable d'environnement IBM_JAVA_OPTIONS est obsolète. Utilisez à la place la nouvelle variable OPENJ9_JAVA_OPTIONS.

Actualisation de service 5 groupe de correctifs 27

Le Fix pack 27 inclut les nouvelles fonctionnalités suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Plus de souplesse dans la gestion de la taille du cache du code JIT: Le cache du code JIT stocke le code natif des méthodes Java compilées. Par défaut, sa taille est de 256 Mo pour une MV 64 bits et de 64 Mo pour une MV 31/32 bits. Dans les anciennes versions, il était possible de l'augmenter (par rapport à sa taille par défaut) en utilisant l'option de ligne de commande -Xcodecachetotal. Dans cette nouvelle version, il devient possible de la réduire avec cette même option, le minimum à respecter étant de 2 Mo. La taille du cache du code JIT affecte également la taille du cache des données JIT, qui contient des métadonnées sur les méthodes compilées. Si vous utilisez l'option -Xcodecachetotal pour gérer la taille du cache du code, la taille du cache des données sera ajustée dans les mêmes proportions.

Actualisation de service 5 groupe de correctifs 30

Le Fix pack 30 inclut les nouvelles fonctionnalités suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Support amélioré pour la récupération de place sans pause

Le mode scavenge simultané (-Xgc:concurrentScavenge) est désormais pris en charge sur les systèmes d'exploitation Windows 64 bits.

L'optimisation à l'état de repos (Idle Tuning) est activée par défaut lorsque la MV fonctionne dans un conteneur Docker

Dans une édition antérieure, un ensemble d'options d'optimisation en veille a été introduit pour gérer l'encombrement du segment de mémoire Java lorsque la machine virtuelle OpenJ9 est à l'état inactif. Désormais, les deux options suivantes sont activées par défaut, ce qui entraîne les comportements décrits lorsque la MV OpenJ9 détecte qu'elle fonctionne dans un conteneur et qu'elle entre dans un état de repos :

-XX:[+|-]IdleTuningGcOnIdle : un cycle de récupération de place est exécuté et libère les pages de mémoire libre pour les rendre au système d'exploitation.
-XX:[+|-]IdleTuningCompactOnIdle : le tas des objets est compacté pour réduire sa fragmentation.

Par défaut, la MV est contrôlée toutes les 180 secondes pour déterminer si elle est à l'état de repos. Pour contrôler le temps d'attente entre les contrôles, utilisez l'option " -XX :[+|-]IdleTuningMinIdleWaitTime ( documentation de l'utilisateur OpenJ9 ). Pour désactiver la détection de l'état de repos, mettez cette option à 0.

Modifications apportées aux droits d'accès au répertoire de cache de classes partagées par défaut (pas Windows)

Si vous n'utilisez pas la sous-option cachDirPerm pour spécifier les autorisations sur un répertoire de cache de classes partagées et si ce répertoire n'est pas le répertoire par défaut /tmp/javasharedresources, les changements suivants s'appliquent :

Lors de la création d'un nouveau répertoire de cache, les autorisations par défaut sont désormais plus strictes.
Si le répertoire de cache existe déjà, les autorisations sont désormais inchangées (auparavant, lorsqu'un cache était ouvert en utilisant ce répertoire, les autorisations étaient réglées à 0777).

Pour plus d'informations, voir -Xshareclasses dans la documentation utilisateurOpenJ9.

Actualisation de service 5 groupe de correctifs 31

Le Fix pack 31 inclut les nouvelles fonctionnalités suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Amélioration des informations de diagnostic pour les systèmes Linux qui implémentent des groupes de contrôle

Si vous utilisez des groupes de contrôle (cgroups) pour gérer des ressources sur des systèmes Linux , des informations sur les limites d'UC et de mémoire sont désormais enregistrées dans un fichier de vidage Java. Ces informations sont particulièrement importantes pour les applications qui fonctionnent dans un conteneur Docker, car lorsque les limites des ressources sont fixées au sein même du conteneur, le moteur Docker compte sur les cgroups pour faire respecter ces limites. Si vous obtenez une erreur Java OutOfMemoryError parce qu'une limite de conteneur a été fixée sur la quantité de mémoire disponible pour une application et que cette allocation n'est pas suffisante, vous pouvez diagnostiquer ce problème à partir du fichier Java dump. Les informations concernant les cgroups se trouvent dans la section ENVINFO.

Ecriture d'un vidage Java dans STDOUT ou STDERR

Vous pouvez maintenant écrire un fichier de vidage Java dans STDOUT ou STDERR à l'aide de l'option de ligne de commande -Xdump .

Support amélioré pour la récupération de place sans pause

Le mode scavenge concurrent est désormais utilisable sur les plateformes suivantes :

Linux sur IBM POWER LE
AIX

Actualisation de service 5 groupe de correctifs 35

Le Fix Pack 35 inclut les mises à jour suivantes :

Support de la nouvelle ère japonaise: Le support de la nouvelle ère japonaise, Reiwa, est ajouté. Pour plus d'informations sur les modifications, voir Modifications de l'ère japonaise pour IBM SDK, Java Technology Edition.
Support de nouvelles versions de systèmes d'exploitation: La prise en charge est ajoutée pour Red Hat Enterprise Linux (RHEL) version 8 et Windows Server 2019. Pour obtenir la liste des systèmes d'exploitation pris en charge, voir Environnements pris en charge.
Modification de la taille de pile native par défaut sous z/OS 64 bits: La taille de pile par défaut des unités d'exécution du système d'exploitation sous z/OS 64 bits passe de 384 Ko à 1 Mo au minimum. Pour plus d'informations sur ce paramètre, voir -Xmso.

Le Fix pack 35 inclut également les nouvelles fonctionnalités et évolutions suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Nouvelle option pour ignorer ou signaler les options -XX: non reconnues: Par défaut, les options -XX: non reconnues sur la ligne de commande sont ignorées afin d'éviter que l'application ne démarre pas. Désormais, vous pouvez utiliser -XX:-IgnoreUnrecognizedXXColonOptions pour faire obstacle à ce comportement et obtenir que les options -XX: non reconnues ne soient pas ignorées, mais au contraire signalées. Pour plus d'informations, voir -XX :[+|-]IgnoreUnrecognizedXXColonOptions dans la documentation utilisateur d'OpenJ9.
Ecriture d'un vidage Java dans STDOUT ou STDERR: Vous pouvez désormais écrire un fichier de vidage Java dans STDOUT ou STDERR à l'aide de l'option de ligne de commande -Xdump . Voir Writing to STDOUT/STDERR dans la documentation utilisateurOpenJ9 pour plus de détails.
Amélioration des informations de diagnostic pour les systèmes Linux qui implémentent des groupes de contrôle: Si vous utilisez des groupes de contrôle (cgroups) pour gérer des ressources sur des systèmes Linux , des informations sur les limites d'UC et de mémoire sont désormais enregistrées dans un fichier de vidage Java. Ces informations sont particulièrement importantes pour les applications qui fonctionnent dans un conteneur Docker, car lorsque les limites des ressources sont fixées au sein même du conteneur, le moteur Docker compte sur les cgroups pour faire respecter ces limites. Si vous obtenez une erreur Java OutOfMemoryError parce qu'une limite de conteneur a été définie sur la quantité de mémoire disponible pour une application et que cette allocation n'est pas suffisante, vous pouvez diagnostiquer ce problème à partir du fichier de vidage Java. Les informations concernant les cgroups se trouvent dans la section ENVINFO. Pour un exemple de sortie, voir Java dump (ENVINFO) dans la documentation utilisateurOpenJ9.
Support amélioré pour la récupération de place sans pause: Le mode de récupération simultanée (-Xgc:concurrentScavenge) est désormais pris en charge sous AIX et Linux sous POWER.
Une nouvelle option dans OpenJ9 permet d'empêcher l'utilisation d'une requête réseau pour déterminer le nom d'hôte et l'adresse IP: Par défaut, pour les besoins de diagnostic et de dépannage, une requête réseau est utilisée pour déterminer le nom d'hôte et l'adresse IP. Si le serveur de noms ne peut être contacté, votre programme doit néanmoins attendre le temps imparti avant de renoncer. Pour éviter cette attente inutile, vous pouvez à présent empêcher que la requête ne soit émise. Pour plus d'informations, voir -XX :[+|-]ReadIPInfoForRAS dans la documentation utilisateur d'OpenJ9.
Nouvelle option expérimentale pour améliorer les performances des champs surveillés par JVMTI: L'option '-XX :[+|-]JITInlineWatches ( documentation de l'utilisateur OpenJ9 ) est introduite dans cette version. Lorsqu'elle est activée, cette option met en fonction les opérations JIT expérimentales destinées à améliorer les performances des champs surveillés par JVMTI. Cette option n'est actuellement prise en charge que sur les plateformes x86 (Windows, macOS, et Linux).
Modification de la taille de pile native par défaut sous z/OS 64 bits: La taille de pile par défaut des unités d'exécution du système d'exploitation sous z/OS 64 bits est passée de 384 Ko à 1 Mo. Pour plus d'informations sur ce paramètre, voir -Xmso.

Actualisation de service 5 groupe de correctifs 36

Le Fix pack 36 inclut les nouvelles fonctionnalités et modifications suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Changements pour le numéro de génération du cache de classes partagées: Sur toutes les plateformes, le format des classes stockées dans le cache de classes partagées a changé. Cela amène la JVM à créer un nouveau cache de classes partagées, plutôt que de recréer ou de réutiliser un cache existant. Pour économiser de l'espace, tous les caches partagés existants peuvent être supprimés sauf s'ils sont utilisés par une édition antérieure.

Actualisation de service 5 groupe de correctifs 37

Le Fix pack 37 inclut les nouvelles fonctionnalités et modifications suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Support des plateformes amélioré pour la récupération de place sans pause: La prise en charge du mode de récupération simultanée est désormais étendue à z/OS et Linux on IBM Z
Support de Transparent HugePage: La machine virtuelle prend désormais en charge l'allocation de pages très volumineuses sous Linux lorsque vous utilisez le paramètre madvise . Pour activer cette fonctionnalité, utilisez l'option -XX:+TransparentHugePage sur la ligne de commande au démarrage de votre application.
-XX :[ L'option+|-]JITInlineWatches est prise en charge par les options " z/OS et " Linux on IBM Z et activée par défaut: Introduite dans une édition antérieure, cette option met en fonction les opérations JIT expérimentales destinées à améliorer les performances des champs surveillés par JVMTI. L'option est désormais prise en charge sous z/OS et Linux on IBM Z, et est activée par défaut.
Support des options de l'OpenJDK HotSpot: L'option -XX:OnOutOfMemoryError de l'OpenJDK Hotspot est à présent supportée pour des raisons de compatibilité.
Retrait de l'option -Xdiagnosticscollector: Cette option était redondante. Elle est à présent retirée.

Actualisation de service 5 groupe de correctifs 40

Le Fix Pack 40 inclut les mises à jour suivantes :

L'implémentation de JDWP est remplacée par son équivalent OpenJDK

JDWP est utilisé pour déboguer des applications Java, par exemple comme indiqué dans Options standard, et Java Virtual Machine Tool Interface dans la documentation OpenJ9 . La précédente implémentation de JDWP est maintenant remplacée par son équivalent OpenJDK. Ce changement vise à éliminer un problème inhérent à la précédente implémentation et à renforcer l'alignement de l'IBM SDK sur l'OpenJDK. Comme ces deux implémentations sont différentes, les options disponibles le sont également. Ces options n'existent plus : version, src, log et trace. Ces options sont nouvelles : launch, onthrow, onuncaught, mutf8 et quiet. Pour plus d'informations sur les options de la nouvelle implémentation de JDWP, consultez l'aide de la ligne de commande :

java -agentlib:jdwp=help

Le Fix pack 40 inclut également les nouvelles fonctionnalités et modifications suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Fixation automatique d'une taille de tas initiale

Comme alternative au dimensionnement et au réglage manuel d'une valeur -Xms par l'utilisateur, la MV peut maintenant déterminer seule et fixer une taille de tas initiale adéquate pour l'application. Elle enregistre la taille du tas à la fin du processus de démarrage et écrit cette donnée dans le cache de classes partagées. Une valeur moyenne est appliquée pendant quelques redémarrages, ce qui aide à s'assurer que la valeur utilisée pour la taille de tas initiale est aussi juste que possible. La taille de tas enregistrée est spécifique à la ligne de commande de l'application. Par conséquent, une suggestion différente est stockée pour chaque ligne de commande unique.

Pour activer ce comportement, utilisez l'option -XX:+UseGCStartupHints sur la ligne de commande au démarrage de votre application.

Heuristiques pour le compactage du tas pendant la phase "idle" du GC

Désormais, la MV compacte automatiquement le tas lorsque certaines conditions sont remplies au cours de la phase "idle" du récupérateur de place. Suite à ce changement, l'option -XX :[+|-]IdleTuningCompactOnIdle est obsolète.

Changement dans le comportement de -XX:IdleTuningCompactOnIdle

L'option -XX:[+|-]IdleTuningCompactOnIdle n'a plus d'effet lorsque l'option -XX:+IdleTuningGcOnIdle n'est pas spécifiée.

Changements dans les interfaces internes

Les interfaces internes de l'API Attach ont subi de légers changements qui concernent la bibliothèque de classes internes du SDK ainsi que les fichiers tools.jar et healthcenter.jar.

Si une application utilise une copie privée du fichier tools.jar d'une édition antérieure, il se peut que l'application ne puisse pas utiliser l'API de connexion dans cette édition car les classes Java ne correspondent pas. Utilisez le fichier tools.jar de cette nouvelle version à la place.
De la même manière, le fichier healthcenter.jar de cette version n'est pas compatible avec les versions plus anciennes.

Actualisation de service 5 groupe de correctifs 41

Le Fix pack 41 inclut les nouvelles fonctionnalités et modifications suivantes dans la machine virtuelle Eclipse OpenJ9 (elles sont décrites dans la documentation utilisateur d'OpenJ9) :

Le réglage automatique de la taille de tas initiale est activé par défaut: L'option -XX:[+|-]UseGCStartupHints, qui, lorsqu'elle était activée, mettait en fonction l'apprentissage automatique et le réglage d'une taille de tas appropriée pour une application, est à présent activée par défaut.
Option pour le partage des classes anonymes de la MV: Dans les anciennes éditions, les classes anonymes, c'est-à-dire créées par Unsafe.defineAnonymousClass, n'étaient pas stockées dans le cache de classes partagées. Elles le sont à présent. Cela signifie qu'elles sont disponibles pour la compilation AOT (ahead-of-time) et peuvent ainsi améliorer les performances au démarrage. Une nouvelle option, -XX:[+|-]ShareAnonymousClasses, a été introduite pour vous permettre d'empêcher le stockage des classes anonymes dans le cache de classes partagées.
Amélioration des performances pour les zones surveillées par JVMTI sur Power Systems: L'option " -XX:[+|-]JITInlineWatches, qui active les opérations JIT afin d'améliorer les performances des champs surveillés par JVMTI, est désormais également prise en charge sur AIX et Linux on Power Systems.
Linux sur x86: prise en charge des pages très volumineuses transparentes (THP): Lorsque vous utilisez le paramètre madvise (/sys/kernel/mm/transparent_hugepage/enabled) sur Linux sur les systèmes x86 , THP est désormais activé par défaut. Pour désactiver cette fonctionnalité, utilisez l'option -XX:-TransparentHugePage sur la ligne de commande au démarrage de votre application. Lorsque vous utilisez madvise, THP demeure désactivé par défaut sur les autres systèmes, mais vous pouvez l'y activer en spécifiant l'option -XX:+TransparentHugePage.
Changements pour le numéro de génération du cache de classes partagées: Le format des classes stockées dans le cache de classes partagées a changé. Cela amène la JVM à créer un nouveau cache de classes partagées, plutôt que de recréer ou de réutiliser un cache existant. Pour économiser de l'espace, vous pouvez supprimer tous les caches partagés existants, sauf s'ils sont utilisés par une édition antérieure. Comme conséquence de ce changement de format, une colonne layer (couche) apparaît à présent dans la sortie produite par l'option -Xshareclasses:listAllCaches. Ce changement vise à prendre en charge une future évolution.