Temurin-build: Shenandoah GC non disponible dans jdk11 AIX et JDK11 window32

https://wiki.openjdk.java.net/display/shenandoah/Main suggère que Win 32 devrait fonctionner mais PPC est peut-être encore en développement par SAP. Je ne suis pas trop préoccupé par l'échec de Win32 car je soupçonne que le cas d'utilisation est 0.

La description
Si les tests de fumée échouent, nous bloquons l'exécution des tests AQA (comme en aucun cas pour continuer, car la construction / l'empaquetage est faux).

Afin de résoudre ce problème, nous devons apporter des modifications au fichier playlist.xml dans ce référentiel.

Un test échoue sur Win32, probablement parce que certains éléments de configuration de compilation ne sont pas définis, et cela devrait être vérifié si c'est le problème, puis corrigé. En attendant, nous devrions exclure le test de la plate-forme win32, mais ce problème devrait rester ouvert jusqu'à ce que nous résolvions les raisons de son échec. Nous pouvons le faire en ajoutant un bloc désactivé à la définition de test dans le fichier de liste de lecture. Quelque chose comme:

<disabled>
    <comment>https://github.com/AdoptOpenJDK/openjdk-build/issues/2566</comment>
    <plat>x86-32_windows</plat>
</disabled>

Pour AIX, car il est encore en développement, nous pourrions ajouter <platformRequirements>^arch.ppc64</platformRequirements> à la définition de test dans le fichier playlist.xml .

📋 étape par étape

Pour résoudre ce problème et apporter un correctif, vous devez consulter la liste étape par étape suivante. Une documentation plus détaillée du flux de travail peut être trouvée ici . Remarque: vous n'avez pas besoin de vous ajouter à un fichier Contributors.md comme indiqué dans les instructions détaillées.

• [] Réclamez ce problème: commentaire ci-dessous.
• [] Forkez le dépôt dans github en cliquant simplement sur le bouton 'fork'.
• [] Découvrez le référentiel forké
• [] Créez une branche de fonctionnalité pour le problème. Nous n'avons pas de définition de nom pour les succursales.
• [ ] Validez vos modifications.
• [] Démarrez une demande d'extraction.
• [] Terminé 👍 Demandez dans les commentaires pour un avis :)
• [] Si le réviseur trouve des pièces manquantes ou un problème, il entamera une discussion avec vous et décrira les étapes suivantes pour résoudre le problème.
• [] Vous l'avez fait 🎉 Nous allons fusionner le correctif dans la branche principale.
• [] Merci, merci, merci de faire partie de ce projet en tant que contributeur open source ❤️

Hmmm mon souvenir flou était qu'il n'avait été implémenté - au moins au début - que pour x64 et aarch64. Fonctionne-t-il sur Linux / ppc64le et Linux / s390x?

Supposera que la table de support à https://wiki.openjdk.java.net/display/shenandoah/Main est exacte, donc non.

https://github.com/AdoptOpenJDK/openjdk-build/blob/master/sbin/build.sh#L79 -L85

L' outpu t de

15:28:53  Running ./configure with arguments 'bash ./configure --verbose  --with-vendor-name=AdoptOpenJDK --with-vendor-url=https://adoptopenjdk.net/ --with-vendor-bug-url=https://github.com/AdoptOpenJDK/openjdk-support/issues --with-vendor-vm-bug-url=https://github.com/AdoptOpenJDK/openjdk-support/issues --without-version-opt --without-version-pre --with-version-build=8 --with-vendor-version-string=AdoptOpenJDK-11.0.11+8 --with-boot-jdk=/cygdrive/c/openjdk/jdk-10 --with-jvm-features=shenandoahgc --with-debug-level=release --with-native-debug-symbols=external --with-jvm-variants=client,server --with-cacerts-file=/cygdrive/e/jenkins/tmp/sbin/../security/cacerts  --disable-warnings-as-errors --disable-ccache --with-target-bits=32 --target=x86 --disable-ccache --with-toolchain-version=2017 '

@adamfarley Puisque vous utilisez toujours un ordinateur portable Windows pour autant que je sache, pouvez-vous jeter un œil à celui-ci?

Je peux y jeter un œil, bien sûr. Je vais le lire.

Je pense que le message d'erreur a été mal interprété. Ça dit:

"On s'attend à ce que Shenandoah soit absent mais il est présent"

Le problème n'est donc pas que nous manquons Shenandoah. Le problème est que nous l'avons, même si le test ne s'y attendait pas.

En vérifiant cela, plus haut, nous voyons:

"INFO: 11.0.11.0 détecté sous WINDOWS / X86, attendez-vous à ce que Shenandoah soit présent: faux"

Inspectera le test. Il se pourrait simplement que Shenandoah ne soit pas encore disponible sur Windows 32 bits lors du développement de ce test de fumée. Ce site Web implique définitivement qu'un Windows Shenandoah 32 bits était prévu.

https://github.com/AdoptOpenJDK/openjdk-build/issues/2566#issuecomment -819824589

La plupart des tests de fumée sont TestNG. Nous pourrions également utiliser disable pour exclure une méthode de test spécifique testShenandoahAvailable (ou EXCLUDE file enable by exclude transform utilitaire dans https://github.com/eclipse/openj9/tree/master/test/Utils/src/org/openj9/test/util ) pour éviter de désactiver l'ensemble de testCase Adopt_HS_FeatureTests .

Aussi, j'ai regardé la sortie du test aix. Je pense que "testShenandoahAvailable" a réussi, car il manquait correctement dans la version AIX.

Le test qui a échoué sur aix était "testJFRAvailable", que je ne crois pas être lié à Shenandoah.

@ sophia-guo - Pourriez-vous soulever un problème distinct pour l'échec "testJFRAvailable" sur AIX?

En ce qui concerne le problème win32 Shenandoah, je crée un PR pour que nous attendions Shenandoah sur Windows 32 bits. Je ne vois aucune exclusion intentionnelle de Shenandoah sur Windows 32 bits dans la demande de modification du page Web du

À moins que quelqu'un ne puisse me dire le contraire, je vais supposer que Windows 32 bits a été simplement ignoré lors des tests de pré-déploiement du test de fumée.

@ sophia-guo - Pourriez-vous passer en revue ma solution proposée ici et me dire ce que vous en pensez? Mon raisonnement est ici .

Si cela vous convient, nous pouvons commencer à suivre le processus de fusion des relations publiques pendant une version, comme indiqué ici .

Edit: J'ai également réalisé que ce changement affecterait également les exécutions de jdk15 +, j'ai donc vérifié et les tests de fumée JDK16u win32 voient également ce problème, donc tout va bien. Deux échecs, un correctif. :)

Merci @adamfarley d' avoir enquêté - votre raisonnement me semble solide 👍

Votre correctif proposé semble bon @adamfarley - veuillez créer un PR pour cela (et nous pouvons suivre le processus de fusion des versions pour décider s'il sera fusionné pendant ou après la publication).

Okie dokie, fera l'affaire. :)

Ok, PR: https://github.com/AdoptOpenJDK/openjdk-build/pull/2580

Malheureusement, Linter n'est pas content.

https://github.com/AdoptOpenJDK/openjdk-build/pull/2580/checks?check_run_id=2365074913

C'est principalement mon vieil ami, la limite de 80 caractères et plusieurs alertes indiquant que chaque numéro du fichier est un nombre magique (?).

Pour m'empêcher de faire de nombreux petits changements à ce fichier aussi près de la version, serait-il correct que nous sautions le linter, vérifiez-le une fois?

J'ai créé https://github.com/AdoptOpenJDK/openjdk-build/issues/2581 pour examiner attentivement le linter et discuter de la nécessité de le mettre à jour pour être plus raisonnable / réaliste. Je vois la priorité sur le fait de sauter le contrôle Linter pour d'autres PR récemment. Il sera bon de le régler au bon niveau de vérification après la publication (et étant donné la priorité, je ne bloquerais pas cette vérification ... mais je m'en remettrai à l'opinion du deuxième critique).

Problème AIX JFR ouvert https://github.com/AdoptOpenJDK/openjdk-build/issues/2582 , il peut être fermé par # 2580.

Merci Sophia. :)