Temurin-build: Создайте пакет, содержащий только символы отладки

@milderhc - похоже, вы добились большого прогресса в этом (с объединенным # 2043), спасибо!

Следующие шаги:

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

Вы возьмете это на себя? Нужна ли вам поддержка, чтобы двигаться вперед?

@smlambert Конечно. Я могу взять их.

Не могли бы вы сказать мне, где находятся скрипты конвейера? А также идея в API - это новый метод, который обслуживает исключительно символы отладки, а также на веб-сайте?

Я не знаком ни с одним из этих репозиториев, это займет некоторое время.

Спасибо @milderhc! Скрипты конвейера находятся в этом репо. Хотя, когда я смотрю на один из PR ,

@ andrew-m-leonard @sxa - @milderhc ?
Все ли, что нужно для фактического обновления конфигурации конвейера для создания отладочных образов?

Работа с API: (работа сделана) https://github.com/AdoptOpenJDK/openjdk-api-v3/pull/130
Работа веб-сайта: (все еще не завершена?) Https://github.com/AdoptOpenJDK/openjdk-website/issues/696 (это менее важно, чем возможность обслуживать debuginfo через API)

Конечно, я могу помочь. @smlambert @milderhc Я хотел проверить, актуальна ли здесь следующая ошибка, которую я помог интегрировать в OpenJDK для jdk-16?
https://bugs.openjdk.java.net/browse/JDK-8252233 Поместите символы отладки в символы-изображение

Думаю, это актуально @ andrew-m-leonard - не могли бы вы обрисовать в общих чертах, что, если необходимы какие-либо дальнейшие изменения для создания этих артефактов в проекте (для сборок горячих точек)?

Таким образом, изменение https://bugs.openjdk.java.net/browse/JDK-8252233 позволило создать чистый образ отладочных символов через цель:

make symbols-image

В результате получится изображение "build / * / images / symbols"
По умолчанию "make product-images", который использует сборки Adopt, включает "symbols-image", поэтому вы должны обнаружить, что у нас уже есть создаваемая папка с изображениями символов, нам просто нужно заархивировать ее ... и заархивировать.

@ andrew-m-leonard - это цель make только для jdk16 + или для всех версий (возможно ли это для всех версий или какой артефакт debuginfo должен создаваться для pre-jdk16)? возможно, вы можете указать место в коде, где можно было бы внести изменения, чтобы включить этот https://github.com/AdoptOpenJDK/openjdk-build/issues/2042#issuecomment -742898474

@milderhc привет, Милдер, я смотрел, что поддерживает openjdk, и в настоящее время они различаются в зависимости от версии:
jdk16 +: при поддержке https://bugs.openjdk.java.net/browse/JDK-8252233 теперь вы можете просто выполнить команду «make symbols-image». "Символы-изображения" являются частью цели make "product-images", и для jdk8 + Adopt уже построена эта цель: https://github.com/AdoptOpenJDK/openjdk-build/blob/87f799024a58d392255eead1cd83d93515410b2ild6 . Это означает, что для jdk16 + мы уже создали образ «build / * / symbols / ..», нам просто нужно заархивировать его в конце сборки, поэтому эта строка должна перемещать папку «symbols»: https: // github.com/AdoptOpenJDK/openjdk-build/blob/88c0d77255264cc92423d534de9c3563d4fb0903/sbin/build.sh#L632 т. е. «$ {BUILD_CONFIG [DEBUG_IMAGE_PATH] + необходимо для jd-символов».

jdk11u & jdk8u: Таким образом, оба они поддерживают make "symbols-image", однако у них нет JDK-8252233, и поэтому он не создает пакет изображений, а просто помещает символы в папку jdk image "lib". Это означает, что у нас есть два варианта:
1) Получите JDK-8252233 с бэкпортированием и используйте тот же метод, что и jdk16 +. Вероятно, это идеальный вариант, но на это потребуется время ...
2) Добавьте логику в sbin / build.sh для перемещения символов из библиотеки в новое место, похоже, вы это уже сделали? https://github.com/AdoptOpenJDK/openjdk-build/blob/88c0d77255264cc92423d534de9c3563d4fb0903/sbin/build.sh#L651 Работает ли это для jdk16 +? в таком случае, возможно, пока игнорируйте JDK-8252233.

Теперь я вижу, что вы добавили новый аргумент сборки: --create-debug-symbols-package, поэтому я думаю, что вопрос, который следует задать, - когда мы хотим, чтобы это значение было истинным? всегда? если это так, просто установите его: https://github.com/AdoptOpenJDK/openjdk-build/blob/master/build-farm/make-adopt-build-farm.sh
Если он требует настройки только на определенных платформах или версиях, то здесь: https://github.com/AdoptOpenJDK/openjdk-build/tree/master/build-farm/platform-specific-configurations

@milderhc - еще один важный факт, который необходимо оценить, прежде чем мы включим --create-debug-symbols-package, - это сколько места архив символов собирается добавить в наши сборки для планирования емкости? Как это собирается добавить xMB для osbuild x вариант x версия ...?
@sxa fyi

Привет @ andrew-m-leonard, спасибо, что изучили это и за подробное объяснение.

Параметр --create-debug-symbols-package работает в jdk8u, jdk11u и jdk16 +. Мы можем включить его прямо в make-adopt-build-farm.sh который, как мне кажется, вызывается конвейером сборки?

Пространство в МБ для jdk11u в Linux составляет около 230 МБ и около 40 МБ для macOS и Windows. В jdk8u это около 100 МБ для LInux и 5 МБ для Windows. Размеры для jdk16 очень похожи на jdk11u.

@milderhc привет, один быстрый вопрос, в чем разница между текущим openj9 "-debug-image" и новым "-debug-symbols"?

Разве openj9 "debug-image" - это не одно и то же? https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/cf49ddabb9e46e90af63e85f03e3e1e71338f6a2/closed/DebugImage.gmk

https://github.com/AdoptOpenJDK/openjdk-build/blob/88c0d77255264cc92423d534de9c3563d4fb0903/sbin/build.sh#L410

имеет ли смысл называть Hotspot одним «отладочным образом»?

Итак, некоторые приблизительные расчеты по размеру:
Платформы, которые кешируют сборки для каждой версии:

• рука: 5x230 МБ = + 1,15 ГБ
• pLinux: 5x230 МБ = + 1,15 ГБ

- Mac: 5x10 МБ = + 50 МБ

Платформы, которые в настоящее время не кэшируют:
AIX: ws очищено
zLinux: ws очищено
Win: кеширует только последнюю сборку в tmp ws
xLinux: Докер
aarch64: Докер

Хранилище архива "главного" узла для всех версий x платформ:

jdk8:
- 11 Linux = 1100MB
- 5 mac & win = 25MB
jdk11:
- 9 Linux = 2160MB
- 4 mac & win = 160MB
jdk15:
- 7 Linux = 1680MB
- 3 mac & win = 120MB
jdk16:
- 7 Linux =1680MB
- 4 mac & win = 160MB
jdk17:
- 7 Linux = 1680MB
- 4 mac & win = 160MB

Таким образом, добавление примерно на 1,1–2,3 ГБ увеличения размера каждой новой заархивированной конвейерной сборки на «мастере» Jenkins.

@sxa fyi

Я сам спрашивал то же самое. Я думаю, они такие же. Фактически, если мы вызовем сценарий для openj9 вместе с --with-debug-symbols-package мы можем получить два пакета. Имеет смысл также переименовать символы отладки в образ отладки.

Я сам спрашивал то же самое. Я думаю, они такие же. Фактически, если мы вызовем сценарий для openj9 вместе с --with-debug-symbols-package мы можем получить два пакета. Имеет смысл также переименовать символы отладки в образ отладки.

да согласен

Я сам спрашивал то же самое. Я думаю, они такие же. Фактически, если мы вызовем сценарий для openj9 вместе с --with-debug-symbols-package мы можем получить два пакета. Имеет смысл также переименовать символы отладки в образ отладки.

Поэтому я думаю, что нам нужно обновить логику, чтобы для openj9 он использовал текущую цель make «debug-image», как и в настоящее время, а для других вариантов использует новую логику, которую вы добавили для создания их «debug-image».

Хорошо, я сначала обновлю это.

@milderhc привет, Милдер, как дела?

@ andrew-m-leonard привет, извините за поздний ответ. Я создал запрос на перенос: https://github.com/AdoptOpenJDK/openjdk-build/pull/2393

@milderhc, спасибо, этот пиар выглядит неплохо. После того, как это будет объединено, остается лишь вопрос:

1. Выполните оценку / влияние емкости инфраструктуры Jenkins: https://github.com/AdoptOpenJDK/openjdk-build/issues/2042#issuecomment -756665091
2. Завершив (1), добавив --create-debug-image if option! = "Openj9" где-нибудь здесь: https://github.com/AdoptOpenJDK/openjdk-build/blob/102237341c7f0737f0dd4dc57fcc7e9e3ffe3bd5/build-farm/make -build-farm.sh # L164

PR очистки выходных данных сборки теперь объединен и должен распространяться по узлам сборки, чтобы вступить в силу. В настоящее время узлами сборки с наиболее ограниченным пространством являются 2 узла плеча, с запасным пространством 3 Гбайт и 4 Гбайт соответственно на данный момент. Внедрение в этот момент уменьшило бы эти 2 машины еще примерно на 1,2 Гб.
Я изучу каждый, чтобы проверить любое неиспользованное использование и контролировать узлы после того, как результат чистой сборки распространится по ним.

Только что изучив build-scaleway-ubuntu1604-armv7-1, очистка вывода сборки должна освободить из него 8 ГБ.

@sxa fyi

Отправлены сборочные конвейеры для arm на jdk8 / 11/16/17
Новое пространство узла руки:

• build-scaleway-ubuntu1604-armv7-1: 18 ГБ
• build-scaleway-ubuntu1604-armv7-2: 19 ГБ
  Итак, мы освободили не менее 6Гб
  Это легко дает нам достаточно места для отладочных изображений.

@milderhc Хотите предложить PR для включения --create-debug-image?
https://github.com/AdoptOpenJDK/openjdk-build/blob/ecb4ce1182b079fb88cc77ce871e3ad1216e4612/build-farm/make-adopt-build-farm.sh#L163

Спасибо, @ andrew-m-leonard, этого будет достаточно для загрузки отладочных образов?

Вот он: https://github.com/AdoptOpenJDK/openjdk-build/pull/2443

Ночные сборки для точки доступа с образами отладки теперь доступны на веб-сайте: https://adoptopenjdk.net/nightly.html?variant=openjdk8&jvmVariant=hotspot

Также через API, например: https://api.adoptopenjdk.net/v3/assets/feature_releases/8/ea?architecture=x64&heap_size=normal&image_type=debugimage&jvm_impl=hotspot&os=linux&page=0&page_size_sizejdk&prod&project_sport_size=10&prod&project=0&page_sizejd&project

Осталось:

• Патч jdk8 для отладки mac для апстрима
• Upstream win debug jdk8 fix
• Исправление отладки AIX для всех версий