Temurin-build: Créer un package de symboles de débogage uniquement

@milderhc - il semble que vous ayez fait de grands progrès sur ce point (avec le #2043 fusionné), merci !

Les prochaines étapes sont-elles :

• mettre à jour les scripts du pipeline de build, afin que ces artefacts soient produits et poussés vers le référentiel des versions
• servi via l'API
• visible sur le site en téléchargement

Allez-vous assumer cela ? Avez-vous besoin d'aide pour faire avancer ce dossier ?

@smlambert Bien sûr. Je peux les prendre.

Pourriez-vous me dire où se trouvent les scripts du pipeline ? Et aussi, l'idée dans l'API serait une nouvelle méthode qui sert exclusivement les symboles de débogage, ainsi que dans le site Web ?

Je ne connais aucun de ces repos, cela prendrait un certain temps.

Merci @milderhc ! Les scripts de pipeline se trouvent dans ce référentiel. Cependant, lorsque je regarde l'un des PR qui a ajouté la prise en charge des images de débogage pour OpenJ9 , je pense qu'une partie du travail est peut-être déjà en place... mais reporte la création d'une équipe pour donner des conseils.

@andrew-m-leonard @sxa - L'un de vous pourrait-il aider @milderhc ?
Est-ce que tout ce qui est nécessaire pour mettre à jour la configuration du pipeline pour créer les images de débogage ?

Travail de l'API : (le travail est terminé) https://github.com/AdoptOpenJDK/openjdk-api-v3/pull/130
Travail sur le site Web : (toujours en suspens ?) https://github.com/AdoptOpenJDK/openjdk-website/issues/696 (c'est moins critique que de pouvoir fournir des informations de débogage via l'API)

Bien sûr que je peux aider. @smlambert @milderhc Je voulais vérifier si le bogue suivant que j'ai aidé à intégrer dans OpenJDK pour jdk-16 est également pertinent ici ?
https://bugs.openjdk.java.net/browse/JDK-8252233 Mettez les symboles de débogage dans les symboles-image

Je suppose que c'est pertinent @andrew-m-leonard - pouvez-vous décrire ce qui, si d'autres modifications sont nécessaires pour produire ces artefacts au niveau du projet (pour les builds hotspot) ?

Ainsi, le changement https://bugs.openjdk.java.net/browse/JDK-8252233 a permis la production d'une image de symboles de débogage pure via la cible :

make symbols-image

Ce qui donnera une image "build/*/images/symbols"
Le "make product-images" par défaut utilisé par les builds Adopt inclut "symbols-image", vous devriez donc constater que nous avons déjà un dossier d'images de symboles en cours de production, nous avons juste besoin de le compresser... et de l'archiver.

@andrew-m-leonard - est-ce que la cible est uniquement pour jdk16+ ou pour toutes les versions (est-ce possible pour toutes les versions, ou quel est l'artefact debuginfo qui devrait être produit pour pré-jdk16) ? vous pouvez peut-être pointer vers l'endroit dans le code où l'on apporterait la modification pour activer ceci étant donné https://github.com/AdoptOpenJDK/openjdk-build/issues/2042#issuecomment -742898474

@milderhc salut Milder, j'ai jeté un œil à ce que supporte openjdk en amont et actuellement ils varient selon la version :
jdk16+ : Avec la prise en charge dans https://bugs.openjdk.java.net/browse/JDK-8252233, vous pouvez désormais simplement émettre "make symbol-image". La "symbols-image" fait partie de la cible de make "product-images", et pour jdk8+ Adopt construit déjà cette cible : https://github.com/AdoptOpenJDK/openjdk-build/blob/87f799024a58d392255eead1cd83d93515410b2e/configureBuild.sh#L206 . Cela signifie que pour jdk16+, nous construisons déjà l'image "build/*/symbols/..", nous avons juste besoin de l'archiver à la fin de la construction, donc cette ligne doit déplacer le dossier "symbols": https:// github.com/AdoptOpenJDK/openjdk-build/blob/88c0d77255264cc92423d534de9c3563d4fb0903/sbin/build.sh#L632 ie."${BUILD_CONFIG[DEBUG_IMAGE_PATH]}" pour "symbols+ doit être".

jdk11u & jdk8u : Donc, ces deux supports créent "symbols-image", mais ils n'ont pas JDK-8252233, et donc il ne produit pas de paquet d'images, mais place simplement les symboles dans le dossier "lib" de l'image jdk. Cela signifie que nous avons deux options ici :
1) Obtenez JDK-8252233 rétroporté et utilisez la même méthode que jdk16+. C'est probablement l'idéal, mais cela prendra du temps...
2) Ajoutez une logique à sbin/build.sh pour déplacer les symboles de lib vers un nouvel emplacement, il semble que vous l'ayez déjà fait ? https://github.com/AdoptOpenJDK/openjdk-build/blob/88c0d77255264cc92423d534de9c3563d4fb0903/sbin/build.sh#L651 Est-ce que cela fonctionne pour jdk16+ ? si c'est le cas, ignorez peut-être JDK-8252233 pour le moment.

Je vois maintenant que vous avez ajouté un nouvel argument de construction : --create-debug-symbols-package, donc je pense que la question à poser est de savoir quand voulons-nous que cet ensemble soit vrai ? toujours? si c'est le cas, il suffit de le configurer dans : https://github.com/AdoptOpenJDK/openjdk-build/blob/master/build-farm/make-adopt-build-farm.sh
S'il ne souhaite être configuré que sur des plates-formes ou des versions spécifiques, cliquez ici : https://github.com/AdoptOpenJDK/openjdk-build/tree/master/build-farm/platform-specific-configurations

@milderhc un autre fait important qui doit être évalué avant d'activer --create-debug-symbols-package, est de savoir combien d'espace supplémentaire l'archive de symboles va-t-elle ajouter à nos versions, pour la planification de la capacité ? Comme cela va ajouter xMB par osbuild x variante x version... ?
@sxa fyi

Salut @andrew-m-leonard, merci d'avoir examiné cela et pour l'explication détaillée.

L'option --create-debug-symbols-package fonctionne dans jdk8u, jdk11u et jdk16+. Nous pouvons l'inclure directement dans make-adopt-build-farm.sh qui, je crois, est appelé par le pipeline de construction ?

L'espace en Mo pour jdk11u sous Linux est d'environ 230 Mo et d'environ 40 Mo pour macOS et Windows. Dans jdk8u, il y a environ 100 Mo pour Linux et 5 Mo pour Windows. Les tailles de jdk16 sont assez similaires à celles de jdk11u.

@milderhc salut, une petite question, quelle est la différence entre l'openj9 "-debug-image" actuel et le nouveau "-debug-symbols" ?

openj9 "debug-image" n'est-il pas la même chose? https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/cf49ddabb9e46e90af63e85f03e3e1e71338f6a2/closed/DebugImage.gmk

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

il serait logique d'appeler Hotspot une "image de débogage" également ?

Donc quelques calculs approximatifs sur la taille:
Plateformes qui mettent en cache les builds pour chaque version :

• bras : 5x230Mo = +1.15Go
• pLinux : 5x230Mo = +1.15Go

- mac : 5x10Mo = +50Mo

Plateformes qui ne mettent pas en cache actuellement :
AIX : ws effacé
zLinux : ws effacé
Win : ne met en cache que la dernière build dans tmp ws
xLinux : Docker
aarch64 : Docker

Stockage d'archive de nœud "maître" pour toutes les plates-formes versions 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

Donc, en ajoutant environ une augmentation supplémentaire de 1,1 à 2,3 Go de la taille de chaque nouvelle construction de pipeline archivée sur Jenkins "master"

@sxa fyi

Je demandais la même chose moi-même. Je pense qu'ils sont les mêmes. En fait, si nous appelons le script pour openj9 avec --with-debug-symbols-package nous pourrions obtenir deux packages. Il est également logique de renommer debug-symbols en debug-image.

Je demandais la même chose moi-même. Je pense qu'ils sont les mêmes. En fait, si nous appelons le script pour openj9 avec --with-debug-symbols-package nous pourrions obtenir deux packages. Il est également logique de renommer debug-symbols en debug-image.

Oui d'accord

Je demandais la même chose moi-même. Je pense qu'ils sont les mêmes. En fait, si nous appelons le script pour openj9 avec --with-debug-symbols-package nous pourrions obtenir deux packages. Il est également logique de renommer debug-symbols en debug-image.

Je pense donc que nous devons mettre à jour la logique afin que pour openj9, il utilise la cible de fabrication "debug-image" actuelle comme il le fait actuellement, et pour les autres variantes, utilise la nouvelle logique que vous avez ajoutée pour créer leur "debug-image".

Ok, je vais mettre à jour ça en premier.

@milderhc salut Milder, comment ça va ?

@andrew-m-leonard salut, désolé pour la réponse tardive. J'ai créé la pull request : https://github.com/AdoptOpenJDK/openjdk-build/pull/2393

@milderhc merci, ce PR a l'air bien. Une fois que cela est fusionné, il s'agit simplement de :

1. Effectuez l'évaluation/l'impact de la capacité de l'infrastructure Jenkins : https://github.com/AdoptOpenJDK/openjdk-build/issues/2042#issuecomment -756665091
2. Après avoir terminé (1), ajoutez --create-debug-image if variant != "openj9" quelque part ici : https://github.com/AdoptOpenJDK/openjdk-build/blob/102237341c7f0737f0dd4dc57fcc7e9e3ffe3bd5/build-farm/make-adopt -build-farm.sh#L164

Le PR de nettoyage de sortie de build est maintenant fusionné et doit se propager à travers les nœuds de build pour prendre effet. Actuellement, les nœuds de construction avec l'espace le plus marginal sont les nœuds à 2 bras, avec un espace libre de 3 Go, 4 Go respectivement à partir de maintenant. L'introduction à ce moment-là marginaliserait ces 2 machines d'environ 1,2 Go supplémentaires.
J'examinerai chacun pour vérifier toute utilisation inactive et surveillerai les nœuds une fois que la sortie de construction propre s'est propagée à travers eux.

Après avoir examiné build-scaleway-ubuntu1604-armv7-1, le nettoyage de sortie de build devrait en libérer 8 Go.

@sxa fyi

Pipelines de construction soumis pour arm le jdk8/11/16/17
Nouvel espace de nœud de bras :

• build-scaleway-ubuntu1604-armv7-1 : 18 Go
• build-scaleway-ubuntu1604-armv7-2 : 19 Go
  Nous avons donc libéré au moins 6 Go
  Cela nous donne facilement suffisamment de marge pour les images de débogage.

@milderhc Souhaitez-vous proposer un PR pour activer --create-debug-image ?
https://github.com/AdoptOpenJDK/openjdk-build/blob/ecb4ce1182b079fb88cc77ce871e3ad1216e4612/build-farm/make-adopt-build-farm.sh#L163

Merci, @andrew-m-leonard, cela suffirait-il pour que les images de débogage soient téléchargeables ?

Le voici : https://github.com/AdoptOpenJDK/openjdk-build/pull/2443

Les builds nocturnes pour hotspot avec images de débogage sont désormais disponibles sur le site Web : https://adoptopenjdk.net/nightly.html?variant=openjdk8&jvmVariant=hotspot

Également via l'API, par exemple : 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=10&project=jdk&sort_method=DEFAULT&pt_sort_order=DEFAULT&pt

Choses restantes :

• Patch jdk8 de débogage mac en amont
• Correctif jdk8 de débogage de win en amont
• Correctif de débogage AIX en amont pour toutes les versions