Temurin-build: Сборщик мусора Shenandoah недоступен в jdk11 AIX и JDK11 window32

https://wiki.openjdk.java.net/display/shenandoah/Main предполагает, что Win 32 должна работать, но PPC все еще может быть в разработке SAP. Меня не слишком беспокоит сбой Win32, поскольку я подозреваю, что вариант использования равен 0.

Описание
Если дымовые тесты терпят неудачу, мы блокируем запуск тестирования AQA (нет смысла продолжать, потому что сборка / упаковка неверны).

Чтобы решить эту проблему, мы должны внести изменения в файл playlist.xml в этом репозитории.

Тест не работает на Win32, возможно, потому, что некоторые параметры конфигурации сборки не установлены, и это должно быть проверено, если это проблема, а затем исправлено. Тем временем мы должны исключить тест для платформы win32, но этот вопрос должен оставаться открытым, пока мы не выясним, почему он не работает. Мы можем сделать это, добавив отключенный блок в определение теста в файле списка воспроизведения. Что-то вроде:

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

Для AIX, поскольку он все еще находится в разработке, мы могли бы добавить <platformRequirements>^arch.ppc64</platformRequirements> к определению теста в playlist.xml .

📋 Шаг за шагом

Чтобы решить эту проблему и внести исправление, вам следует проверить следующий пошаговый список. Более подробную документацию по рабочему процессу можно найти здесь . Примечание. Вам не нужно добавлять себя в файл Contributors.md, как указано в подробных инструкциях.

• [] Заявите о проблеме: комментарий ниже.
• [] Разветвите репозиторий в github, просто нажав кнопку «fork».
• [] Ознакомьтесь с разветвленным репозиторием
• [] Создайте функциональную ветку для проблемы. У нас нет определения именования веток.
• [] Зафиксируйте свои изменения.
• [] Запустить запрос на включение.
• [] Готово 👍 Попросите в комментариях оставить отзыв :)
• [] Если рецензент обнаружит недостающие части или проблему, он начнет с вами обсуждение и опишет следующие шаги, как решить проблему.
• [] Вы сделали это 🎉 Мы объединим исправление в основной ветке.
• [] Спасибо, спасибо, спасибо за то, что участвуете в этом проекте в качестве участника открытого исходного кода ❤️

Хммм, у меня смутное воспоминание заключалось в том, что это было реализовано только - по крайней мере, изначально - для x64 и aarch64. Работает ли он на Linux / ppc64le и Linux / s390x?

Предположим, что таблица поддержки на https://wiki.openjdk.java.net/display/shenandoah/Main является точной, поэтому нет.

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

Результат задания сборки win32 имеет --with-jvm-features = shenandoahgc в качестве аргумента сценария сборки:

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 Поскольку вы все еще используете ноутбук с Windows, насколько я знаю, можете ли вы взглянуть на этот?

Я могу взглянуть, конечно. Буду читать.

Я думаю, что сообщение об ошибке было неправильно истолковано. Он говорит:

«Ожидается, что Шенандоа нет, но он присутствует»

Так что проблема не в том, что нам не хватает Шенандоа. Проблема в том, что он у нас есть, хотя тест этого не ожидал.

Проверяя это, дальше мы видим:

«ИНФОРМАЦИЯ: обнаружен 11.0.11.0 в WINDOWS / X86, ожидается присутствие Шенандоа: false»

Осмотрю тест. Просто могло случиться так, что Shenandoah еще не был доступен для 32-битной Windows во время разработки этого дымового теста. Этот веб-сайт определенно подразумевает, что планировалась 32-битная Windows Shenandoah.

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

Большинство дымовых тестов - это TestNG. Мы также могли бы использовать disable, чтобы исключить конкретный метод тестирования testShenandoahAvailable (или включить файл EXCLUDE, исключив утилиту преобразования в https://github.com/eclipse/openj9/tree/master/test/Utils/src/org/openj9/test/util ), чтобы избежать отключения всего testCase Adopt_HS_FeatureTests .

Также я посмотрел на результат теста aix. Я думаю, что "testShenandoahAvailable" прошел, так как он правильно отсутствовал в сборке AIX.

Тест, который провалился на aix, был "testJFRAvailable", который, я не думаю, связан с Shenandoah.

@ sophia-guo - Не могли бы вы поднять отдельный вопрос, связанный с ошибкой "testJFRAvailable" в AIX?

Что касается проблемы с Win32 Shenandoah, я создаю PR, чтобы мы ожидали Shenandoah на 32-битной Windows. Я не вижу намеренного исключения Shenandoah в 32- разрядной версии Windows в веб-страница проекта определенно подразумевает, что 32-разрядная версия Windows может использовать Shenandoah, если во время сборки были установлены правильные параметры.

Если кто-то не скажет мне иначе, я предполагаю, что 32-разрядная версия Windows просто пропущена во время тестирования перед развертыванием дымового теста.

@ sophia-guo - Не могли бы вы просмотреть здесь предложенное мной исправление и сообщить, что вы думаете? Мои рассуждения здесь .

Если вам это кажется правильным, мы можем начать процесс объединения PR во время выпуска, как описано здесь .

Изменить: также понял, что это изменение также повлияет на запуск jdk15 +, поэтому я проверил, и тесты дыма JDK16u win32 также видят эту проблему, так что все в порядке. Два сбоя, одно исправление. :)

Спасибо @adamfarley за расследование - мне кажутся убедительными ваши доводы 👍

Предлагаемое вами исправление выглядит хорошо

Okie dokie, подойдет. :)

Хорошо, PR: https://github.com/AdoptOpenJDK/openjdk-build/pull/2580

К сожалению, Линтер недоволен.

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

В основном это мой старый друг, ограничение строки 80 символов и несколько предупреждений о том, что каждое число в файле является магическим числом (?).

Чтобы уберечь меня от внесения множества мелких изменений в этот файл так близко к выпуску, можно ли пропустить эту проверку линтером один раз?

Я создал https://github.com/AdoptOpenJDK/openjdk-build/issues/2581, чтобы тщательно изучить линтер и обсудить, следует ли его обновлять, чтобы сделать его более разумным / реалистичным. Я считаю, что в последнее время предпочтительнее пропускать проверку Линтером другие PR. Было бы хорошо установить его на правильный уровень проверки пост-релиза (и, учитывая приоритет, я бы не блокировал эту проверку ... хотя и полагаюсь на мнение 2-го рецензента).

Проблема AIX JFR открыта https://github.com/AdoptOpenJDK/openjdk-build/issues/2582 , это может быть близко к # 2580.

Спасибо, София. :)