Problèmes et limitations de J9

Problèmes ou limitations connus que vous pouvez rencontrer dans des environnements système ou configurations spécifiques.

Les vidages système sont introuvables sous SLES 12 (Linux uniquement)

Sous SLES 12 et versions ultérieures, les fichiers de vidage système ne sont plus créés dans le répertoire personnel de l'utilisateur lorsque la JVM les demande. A la place, les fichiers avec une extension .xz sont créés dans le répertoire /var/lib/systemd/coredump/. Ce comportement est conforme à ce qui est attendu, dans la mesure où SLES 12 introduit le démon systemd en remplacement du démon init de System V, qui n'est pas supporté par la JVM Eclipse OpenJ9.

Vous pouvez toujours lire ces vidages core avec l'outil afficheur de vidage (jdmpview) en suivant ces étapes :
  1. Extrayez le cliché de base en exécutant tar -xf *.xz, qui génère un fichier de vidage de base non compressé sans extension de fichier.
  2. Pour ouvrir le vidage avec l'afficheur de vidage, spécifiez la commande suivante sur la ligne de commande :
    jdmpview -core <filename>
    Où <filename> est le fichier de vidage principal extrait.
Si vous voulez compresser le vidage, les fichiers exécutables et les bibliothèques en un seul fichier .zip, vous pouvez recourir à l'utilitaire jextract, puis passer le zip résultant à l'afficheur de vidage en utilisant la commande suivante :
jdmpview -zip <filename.zip>

Pour plus d'informations sur l'afficheur de vidage (jdmpview), voir Afficheur de vidage dans la documentation utilisateur d' OpenJ9 .

Un changement de la taille de page par défaut augmente l'utilisation de mémoire (AIX uniquement)
Le tas est alloué avec des pages de 64 ko par défaut à la place de pages de 4 ko. Cette modification améliore les performances de l'application et les performances de démarrage. Toutefois, elle peut augmenter légèrement la quantité de mémoire utilisée par l'application. Si l'utilisation de la mémoire est importante pour l'application, suivez ces étapes pour revenir à des pages de 4 Ko :
  1. Définissez la variable d'environnement LDR_CNTRL=TEXTPSIZE=4K@DATAPSIZE=4K@STACKPSIZE=4K. Pour plus d'informations sur cette variable d'environnement, voir Configuration de votre système dans la documentation utilisateur OpenJ9 .
  2. Utilisez l'option -Xlp4K. Pour plus d'informations sur l'option -Xlp, voir -Xlp dans la documentation utilisateur OpenJ9.
La modification n'a aucune incidence si vous utilisez déjà l'option -Xlp pour allouer le tas à de grandes pages.

Limitation des possibilités de mesure du temps UC utilisateur d'une unité d'exécution avec les méthodes de ThreadMXBean (Linux et z/OS uniquement)

Il n'est pas possible de faire la distinction entre le temps UC en mode utilisateur et le temps UC en mode système sur cette plateforme. ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime()et ThreadMXBean.getCurrentThreadCpuTime() renvoient tous le temps UC total pour l'unité d'exécution requise.

Sous z/OS® , vous pouvez obtenir le temps UC uniquement pour l'unité d'exécution en cours en appelant ThreadMXBean.isCurrentThreadCpuTimeSupported(). L'appel ThreadMXBean.isThreadCpuTimeSupported() retourne la valeur false, car il n'est pas possible d'obtenir le temps UC pour une unité d'exécution autre que l'unité d'exécution en cours.

Signal SIGSEGV lors de la création d'une machine virtuelle Java avec JNI (Linux uniquement)

Un appel de JNI_CreateJavaVM() à partir d'une application JNI peut entraîner un défaut de segmentation (signal SIGSEGV). Pour l'éviter, recompilez votre programme JNI en spécifiant l'option –lpthread.

Manque de ressources dans les applications hautement compartimentées en unités d'exécution (Linux uniquement)
Si votre application fonctionne avec de nombreuses unités d'exécution concurrentes, le message suivant peut s'afficher :
java.lang.OutOfMemoryError
Il indique que la machine commence à manquer de ressources et les messages peuvent avoir les origines suivantes :
  • Si votre installation Linux® utilise LinuxThreadsau lieu de NPTL, le nombre de processus créés dépasse votre limite utilisateur.
  • Les ressources système sont insuffisantes pour créer de nouvelles unités d'exécution. Dans ce cas, d'autres exceptions peuvent être générées en fonction du système d'exploitation sur lequel l'application est exécutée.
  • La mémoire du noyau est insuffisante ou fragmentée. Vous pouvez voir les messages du noyau Out of Memory dans /var/log/messages. Les messages sont associés à l'ID du processus arrêté.

Essayez de régler votre système pour augmenter les ressources système correspondantes.

Support d'AESNI sur les plateformes x86 (Linux et Windows uniquement)

L'exploitation par les logiciels des instructions AESNI sur les architectures x86 n'est pas prise en charge actuellement avec les politiques de récupération de place équilibrée (balanced) et Metronome.

Options d'exécution Language Environment ® entraînant des fins anormales (z/OS uniquement)

Si l'option d'exécution de Language Environment TERMTHDACT est définie sur UAIMM, des fins anormales 0C7 inattendues peuvent être signalées. Bien que les fins anormales soient signalées, l'exécution de la machine virtuelle Java™ se poursuit. Toutefois, si l'option d'exécution de Language Environment ERRCOUNT est définie sur une valeur supérieure à zéro, la machine virtuelle Java peut se terminer lorsque la valeur que vous avez spécifiée pour ERRCOUNT est atteinte. Ce comportement a lieu sur les environnements 31 et 64 bits. Pour éviter ce problème, exécutez la machine virtuelle Java avec l'option -Xrs:sync . Cette option supprime l'utilisation des instructions compare-and-trap et load-and-trap par le compilateur JIT, tout en permettant à la machine virtuelle Java de gérer les signaux synchrones. Par exemple, vous pouvez toujours utiliser le signal SIGQUIT pour collecter un vidage javacore ou le signal SIGTERM pour arrêter la machine virtuelle Java. Pour plus d'informations sur cette option, voir -Xrs dans la documentation utilisateur OpenJ9 .

Pour remplacer le paramètre TERMTHDACT à l'échelle du système, vous pouvez transmettre un paramètre Language Environment qui exclut l'option UAIMM dans votre travail par lots. Par exemple :
// LEPARM='TERMTHDACT(TRACE,CESE,00000096),ERRCOUNT(0)'
Remarque: ne définissez pas l'option TRAP (OFF) pour empêcher la notification des fins anormales, car ce paramètre désactive le traitement du signal POSIX , dont dépend la machine virtuelle Java. Si l'option TRAP (OFF) est requise, par exemple lorsque vous mélangez des programmes Java avec des programmes z/OS natifs, exécutez la machine virtuelle Java avec l'option -Xrs , qui supprime toutes les utilisations des signaux par la machine virtuelle Java. Pour plus d'informations sur l'option TRAP, voir la documentation de votre version de z/OS, par exemple: TRAP.
Unités d'exécution en tant que processus (Linux uniquement)
Sur les systèmes Linux , la machine virtuelle implémente des unités d'exécution Java en tant qu'unités d'exécution natives. Sur le systèmes NPTL tels que RHEL et SLES, elles sont implémentées en tant qu'unités d'exécution. Toutefois, l'utilisation de la bibliothèque LinuxThreads a pour conséquence que chaque unité d'exécution est un processus Linux distinct.
Si le nombre d'unités d'exécution Java dépasse le nombre maximal de processus autorisé, votre programme peut:
  • Recevoir un message d'erreur
  • Obtenir une erreur SIGSEGV
  • Arrêter
La taille de pile native est le principal frein à l'utilisation d'unités d'exécution multiples. Utilisez l'option -Xss pour réduire la taille de la pile d'unités d'exécution de sorte que la machine virtuelle Java puisse gérer le nombre d'unités d'exécution requis. Par exemple, réglez-la à 32 ko au démarrage.
Restrictions concernant les piles flottantes
Si vous êtes en cours d'exécution sans piles flottantes, quel que soit le paramètre défini pour -Xss, une taille de pile native minimale de 256 Ko est fournie pour chaque unité d'exécution.
Sur un système Linux à pile flottante, les valeurs -Xss sont utilisées. Si vous effectuez une migration à partir d'un système Linux à pile non flottante, assurez-vous que les valeurs -Xss sont suffisamment élevées et qu'elles ne reposent pas sur un minimum de 256 Ko.
Restrictions glibc
Si vous recevez un message indiquant que la bibliothèque libjava.so n'a pas pu être chargée en raison d'un symbole non trouvé (par exemple, __bzero), vous pouvez avoir une version antérieure de la bibliothèque GNU C Runtime Library, glibc, installée. L'implémentation de l'unité d'exécution SDK for Linux requiert glibc version 2.3.2 ou ultérieure.
Utilisation de -Xshareclasses:destroy au cours du démarrage de la JVM
Lors de l'exécution de la commande java -Xshareclasses:destroy sur un cache partagé utilisé par une seconde JVM au démarrage, les problèmes suivants peuvent apparaître :
  • La seconde JVM échoue.
  • Le cache partagé est supprimé.

Les demandes de grandes pages échouent

Aucun message d'erreur n'est émis lorsque la machine virtuelle Java n'est pas en mesure de traiter la demande -Xlp.

Cette situation peut avoir plusieurs causes. Par exemple, il peut exister un nombre insuffisant de grandes pages dans le système au moment de la demande. Pour vérifier si la demande -Xlp a été honorée, vous pouvez consulter la sortie de -verbose:gc. Recherchez les attributs requestedPageSize et pageSize dans le fichier journal -verbose:gc. L'attribut requestedPageSize contient la valeur spécifiée par -Xlp. L'attribut pageSize est la taille de page réelle utilisée par la machine virtuelle Java.

Le temps UC retourné par les méthodes de ThreadMXBean peut ne pas être monotone sur les systèmes SMP.

Sur les systèmes SMP, les mesures de temps retournées par ThreadMXBean.getThreadUserTime(), ThreadMXBean.getThreadCpuTime(), ThreadMXBean.getCurrentThreadUserTime() et ThreadMXBean.getCurrentThreadCpuTime() n'augmentent pas toujours selon une fonction monotone si l'unité d'exécution concernée migre vers un processeur différent.