Liste des correctifs pour Amazon Corretto 8

Cette section répertorie tous les correctifs appliqués à OpenJDK pour Amazon Corretto 8. Nous fournissons également des liens vers les problèmes dans le projet OpenJDK.

[C8-1] Empêcher l'erreur prématurée OutOfMemoryException lorsque l'appel G1 GC suspendu par un appel natif de longue durée.

Les programmes qui utilisent le G1 GC pouvaient rencontrer des exceptions de mémoire insuffisante (OOM) intempestives, même lorsque le tas Java était loin d'être saturé. Ce problème se produisait lorsqu'une boucle ayant attendu des appels natifs de longue durée renonçait après seulement deux phases. Ce petit correctif permet de laisser cette boucle attendre aussi longtemps que nécessaire. En règle générale, il suffit de quelques phases supplémentaires. Dans le pire des cas, un processus GC finirait par être exécuté (grâce à JDK-8137099) et résoudre le problème. Le correctif inclut un test unitaire qui crée une situation dans laquelle plus de deux phases sont nécessaires. Il ne réussit que si le correctif est mis en œuvre. Consultez JDK-8137099 pour échanger à ce sujet.

[C8-2] Rétroportage à partir d'OpenJDK 10, corrigeant le problèmeJDK-8177809 : « File.lastModified () perd millisecondes (toujours en 000) ».

Le correctif supprime les incohérences dans la façon dont l'horodatage de dernière modification d'un fichier est présenté. Il standardise le comportement entre les plateformes de génération et les méthodes Java afin que l'utilisateur bénéficie d'une précision de deuxième niveau. Consultez JDK-8177809.

[C8-3] Rétroportage à partir d'OpenJDK9,fixation JDK-8150013, « ParNew : Liste des méthodes de pruneaux récupérables ».

Ce correctif permet de réduire les temps de latence de pause pour le nettoyage de mémoire en parallèle et CMS. L'« analyse racine » GC est jusqu'à trois fois plus rapide en réduisant les contrôles de code redondants.

[C8-4] Rétroportage à partir d'OpenJDK 9, corrigeant le problème JDK-8047338 : « javac is not correctly filtering non-members methods to obtain the function descriptor ».

Ce correctif résout un bogue de compilateur qui provoquait des erreurs au moment de la compilation lorsqu'une interface fonctionnelle générait une exception qui rallongeait l'exception.

[C8-5] Rétroportage à partir d'OpenJDK 10, corrigeant le problème JDK-8144185 : « javac produces incorrect RuntimeInvisibleTypeAnnotations length attribute ».

Ce problème entraînait des échecs de Findbugs, JaCoCo et Checker Framework sur certains programmes d'entrée au format correct.

[C8-6] Déclencher le nettoyage d'une table de chaînes dans G1 en fonction de sa croissance.

Ce correctif déclenche les collections G1 « mixtes » nécessaires pour nettoyer les entrées de la table de chaînes en fonction de la croissance de la table, et pas seulement de l'utilisation du tas Java. Ce dernier facteur est une mesure indépendante, et son déclenchement peut être trop rare (voire inexistant) dans certaines applications. Dans ce cas, la table de chaînes peut croître sans limites, ce qui donne effectivement lieu à une fuite de mémoire native. Consultez JDK-8213198.

[C8-7] Backport depuis OpenJDK 9, correctionJDK-8149442 : « MonitorInUseLists doit être activé par défaut, dégonflez les moniteurs inactifs en prenant trop de temps ».

Ce correctif définit comme paramètre par défaut la suppression d'un goulot d'étranglement en matière de performances pour les applications qui sollicitent fortement les threads. L'activation de MonitorInUseLists permet une diminution plus efficace des moniteurs potentiellement en utilisation uniquement, au lieu de la totalité des moniteurs.

[C8-8] Port arrière d'OpenJDK 11, fixationJDK-8198794 : « Rétroportage au démarrage de Cassandra 3.11.1 avec libnuma 2.0.3 ».

Ce correctif empêche le blocage de Cassandra 3.11.1 au démarrage.

[C8-9] Port arrière d'OpenJDK 11, fixationJDK-8195115 : « G1 Old Gen MemoryPool CollectionUsage.Les valeurs utilisées ne reflètent pas les résultats de GC mixtes ».

Sans ce correctif, il est impossible de déterminer le niveau de saturation du tas à l'aide de JMX lors de l'utilisation du G1 GC.

[C8-10] Accélérer Class.getSimpleName() et Class.getCanonicalName().

La mémorisation accélère nettement ces fonctions. Ce correctif inclut des tests unitaires pour vérifier son bon fonctionnement. Consultez JDK-8187123.

[C8-11] Rétroportage de JDK-8068736 à partir d'OpenJDK9, corrigeant le problème « Avoid synchronization on Executable/Field.declaredAnnotations ».

Améliore les performances de la fonction Executable/Field.declaredAnnotations() par une mise en cache du résultat qui évite la synchronisation de threads.

[C8-12] Rétroportage à partir d'OpenJDK 9, corrigeant le problèmeJDK-8077605 : « L'initialisation des champs statiques provoque une récursion sans limite dans javac ».

[C8-13] Résolution de l'erreur JDK-8130493 : « javac silently ignores malformed classes in the annotation processor ».

javac digérait silencieusement des fichiers de classe incorrects dans un processeur d'annotation et renvoyait un code de sortie 0. Avec ce correctif, javac fournit un message d'erreur et renvoie un code de sortie autre que zéro.

[C8-14] Amélioration du message d'erreur pour l'outil jmap.

Mise à jour des messages d'erreur afin qu'ils proposent d'autres méthodes lorsque le processus cible ne répond pas. Consultez JDK-8213443.

[C8-15] Correction du JDK-8185005 : « Améliorez les performances de ThreadMXBean.getThreadInfo (long ids [], int maxDepth) ».

Ce correctif améliore les performances d'une fonction JVM interne qui recherche une instance de thread Java à partir d'un ID de thread de système d'exploitation. Plusieurs appels ThreadMXBean tirent profit de cette amélioration, tels que getThreadInfo(), getThreadCpuTime() et getThreadUserTime(). L'amélioration relative des performances augmente avec le nombre de threads dans la JVM, puisque la recherche linéaire est remplacée par une recherche dans des tables de hachage.

[C8-16] Port arrière d'OpenJDK 12, fixationJDK-8206075 : « Sur x86, affirmez sur les étiquettes d'assembleur non liées utilisées comme cibles de branche ».

Les instances de classe Étiquette (utilisées pour définir un code d'assemblage) peuvent être utilisées de manière incorrecte dans les instances C1 et Interpreter. L'erreur la plus courante pour une étiquette est d'afficher l'état « ramifiée à » sans jamais être définie comme un emplacement dans le code via la fonction bind(). Une assertion a été ajoutée pour repérer ces cas et a donc déclenché l'échec des tests 106 jtreg/hotspot et 17 jtreg/jdk. Nous avons ensuite déterminé que l'étiquette backedge_counter_overflow n'était pas liée lorsque la valeur de UseLoopCounter était True, mais que la valeur de UseOnStackReplacement était False. Ce problème est désormais résolu les tests ci-dessus l'empêchent de se produire.

[C8-17] Amélioration de la portabilité du code source de la JVM lors de l'utilisation de gcc7.

Ce correctif place des déclarations de type mises à jour dans toutes les situations où le commutateur gcc « -Wno-deprecated-declarations » signalait des problèmes. Il permet également au commutateur d'intercepter d'autres problèmes futurs liés. Cela permet de compiler le code source sur toutes les versions d'Amazon Linux actuelles. Il s'agit d'une combinaison d'une grande partie des problèmes JDK-8152856, JDK-8184309, JDK-8185826, JDK-8185900, JDK-8187676, JDK-8196909, JDK-8196985, JDK-8199685, JDK-8200052, JDK-8200110, JDK-8209786, JDK-8210836, JDK-8211146, JDK-8211370, JDK-8211929, JDK-8213414 et JDK-8213575.

[C8-18] Rétroportage à partir de JDK 10, fixationJDK-8195848 : « Le test JTREG pour StartManagementAgent échoue ».

Pour plus d'informations, consultez la page http://serviceability-dev.openjdk.java.narkive.com/cDFwZce9.

[C8-19] Réactivation d'une suite de chiffrement héritée/désactivée pour réussir deux tests TCK qui échoueraient autrement.

 

Trois rétroportages d'OpenJDK9 pour prendre en charge l'utilisation des bibliothèques préinstallées.

Articles rétroportés : JDK-8043805 pour libjpeg,JDK-8035341 pour libpng, etJDK-8042159 pour lcms2.

Intégration du support aarch64 depuis IcedTea 3.8.

 

Mises à jour des métadonnées liées au fournisseur.

Identifie Amazon en tant que fournisseur de cette distribution OpenJDK et ajoute des liens hypertexte pour signaler les problèmes.

Port arrière d'OpenJDK 9, fixationJDK-8048782 : « OpenJDK : PiscesCache : l'arrondi de xmax/ymax peut provoquer une RasterFormatException ».

Ce bogue est liée au constructeur sun.java2d.pisces.PiscesCache qui accepte les arguments '(int minx, int miny, int maxx, int maxy)' : les 'bboxX1' et 'bboxY1' internes sont définis sur des valeurs supérieures à des valeurs maximales données X et Y.