Temurin-build: डिबग सिंबल-ओनली पैकेज बनाएं

@milderhc - ऐसा लगता है कि आपने इस पर बहुत प्रगति की है (# 2043 विलय के साथ), धन्यवाद!

इसके लिए अगले चरण हैं:

• बिल्ड पाइपलाइन स्क्रिप्ट को अपडेट करें, ताकि इन कलाकृतियों का उत्पादन किया जा सके और रिलीज़ रेपो में धकेला जा सके
• एपीआई के माध्यम से परोसा गया
• डाउनलोड के लिए वेबसाइट पर दिखाई दे रहा है

क्या आप इसे जारी रखेंगे? क्या आपको इसे आगे बढ़ाने के लिए किसी समर्थन की आवश्यकता है?

@smlambert ज़रूर। मैं इन्हें ले सकता हूं।

क्या आप मुझे बता सकते हैं कि पाइपलाइन स्क्रिप्ट कहाँ हैं? और साथ ही, एपीआई में विचार एक नई विधि होगी जो डिबग प्रतीकों के साथ-साथ वेबसाइट में विशेष रूप से कार्य करती है?

मैं उन रेपो में से किसी से परिचित नहीं हूँ, इसमें कुछ समय लगेगा।

धन्यवाद @milderhc! इस रेपो में पाइपलाइन स्क्रिप्ट हैं। हालांकि, जैसा कि मैं उन पीआर में से एक को देखता हूं

@andrew-m-leonard @sxa - क्या आप में से कोई @milderhc की सहायता कर
क्या डीबग छवियों को बनाने के लिए वास्तव में पाइपलाइन कॉन्फ़िगरेशन को अपडेट करने के लिए आवश्यक है?

एपीआई कार्य: (काम हो गया है) https://github.com/AdoptOpenJDK/openjdk-api-v3/pull/130
वेबसाइट का काम: (अभी भी बकाया है?) https://github.com/AdoptOpenJDK/openjdk-website/issues/696 (यह एपीआई के माध्यम से डिबगइन्फो की सेवा करने में सक्षम होने से कम महत्वपूर्ण है)

ज़रूर मैं मदद कर सकता हूँ। @smlambert @milderhc मैं यह जांचना चाहता था कि क्या निम्नलिखित बग मैंने jdk-16 के लिए OpenJDK में एकीकृत करने में मदद की है, यहाँ भी प्रासंगिक है?
https://bugs.openjdk.java.net/browse/JDK-8252233 प्रतीकों-छवि में डीबग प्रतीकों को रखें

मुझे लगता है कि यह प्रासंगिक है @ एंड्रयू-एम-लियोनार्ड - क्या आप इस बात की रूपरेखा तैयार कर सकते हैं, यदि परियोजना में इन कलाकृतियों का उत्पादन करने के लिए किसी और बदलाव की आवश्यकता है (हॉटस्पॉट बिल्ड के लिए)?

तो परिवर्तन https://bugs.openjdk.java.net/browse/JDK-8252233 ने लक्ष्य के माध्यम से एक शुद्ध डीबग प्रतीक छवि के उत्पादन को सक्षम किया:

make symbols-image

जिसके परिणामस्वरूप "बिल्ड/*/छवियों/प्रतीकों" छवि होगी
डिफ़ॉल्ट "उत्पाद-छवियां बनाएं" जो एडॉप्ट बिल्ड उपयोग में "प्रतीक-छवि" शामिल है, इसलिए आपको पता होना चाहिए कि हमारे पास पहले से ही एक प्रतीक छवि फ़ोल्डर का उत्पादन किया जा रहा है, हमें बस इसे ज़िप करने की आवश्यकता है ... और संग्रह।

@ एंड्रयू-एम-लियोनार्ड - क्या यह केवल jdk16+ या सभी संस्करणों के लिए लक्ष्य बनाता है (क्या यह सभी संस्करणों के लिए संभव है, या डिबगइन्फो आर्टिफैक्ट क्या है जिसे प्री-जेडीके 16 के लिए उत्पादित किया जाना चाहिए)? शायद आप कोड में उस स्थान को इंगित कर सकते हैं जहां कोई इसे सक्षम करने के लिए परिवर्तन करेगा https://github.com/AdoptOpenJDK/openjdk-build/issues/2042#issuecomment -742898474

@milderhc हाय मिल्डर, मैं देख रहा हूं कि अपस्ट्रीम ओपनजेडके क्या समर्थन करता है और वर्तमान में वे संस्करण द्वारा भिन्न होते हैं:
jdk16+ : https://bugs.openjdk.java.net/browse/JDK-8252233 में समर्थन के साथ अब आप बस "प्रतीक-छवि बनाएं" जारी कर सकते हैं। "प्रतीक-छवि" "उत्पाद-छवियों" लक्ष्य बनाने का हिस्सा है, और jdk8+ के लिए अपनाना पहले से ही उस लक्ष्य को बनाता है: https://github.com/AdoptOpenJDK/openjdk-build/blob/87f799024a58d392255eead1cd83d93515410b2e/configureBuild.sh#L206 . इसका मतलब है कि jdk16+ के लिए हम पहले से ही "बिल्ड/*/सिंबल्स/.." इमेज बना चुके हैं, हमें इसे बिल्ड के अंत में आर्काइव करने की जरूरत है, इसलिए इस लाइन को "सिंबल्स" फोल्डर को मूव करने की जरूरत है: https:// github.com/AdoptOpenJDK/openjdk-build/blob/88c0d77255264cc92423d534de9c3563d4fb0903/sbin/build.sh#L632 यानी।"${BUILD_CONFIG[DEBUG_IMAGE_PATH]}" jdk16+ के लिए "प्रतीक" होना चाहिए।

jdk11u और jdk8u: तो ये दोनों समर्थन "प्रतीक-छवि" बनाते हैं, हालांकि उनके पास जेडीके -8252233 नहीं है, और इसलिए यह एक छवि बंडल नहीं बनाता है, लेकिन केवल जेडीके छवि "lib" फ़ोल्डर में प्रतीकों को रखता है। इसका मतलब है कि हमारे पास यहां दो विकल्प हैं:
1) JDK-8252233 बैकपोर्ट प्राप्त करें और उसी विधि का उपयोग करें जैसे jdk16+। यह शायद आदर्श है, लेकिन इसमें समय लगेगा...
2) प्रतीकों को lib से एक नए स्थान पर ले जाने के लिए sbin/build.sh में तर्क जोड़ें, ऐसा लगता है कि आप पहले ही ऐसा कर चुके हैं? https://github.com/AdoptOpenJDK/openjdk-build/blob/88c0d77255264cc92423d534de9c3563d4fb0903/sbin/build.sh#L651 क्या यह jdk16+ के लिए काम करता है? यदि ऐसा है तो शायद फिलहाल के लिए JDK-8252233 को अनदेखा करें।

अब मैं देख रहा हूं कि आपने एक नया बिल्ड arg: --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, क्षमता नियोजन के लिए प्रतीक संग्रह हमारे निर्माण में कितना अधिक स्थान जोड़ने जा रहा है? चूंकि यह एक्सएमबी प्रति ओएसबिल्ड एक्स संस्करण एक्स संस्करण जोड़ने जा रहा है ...?
@sxa fyi

हाय @ एंड्रयू-एम-लियोनार्ड, इसे देखने और विस्तृत स्पष्टीकरण के लिए धन्यवाद।

--create-debug-symbols-package विकल्प jdk8u, jdk11u, और jdk16+ में काम करता है। हम इसे सीधे make-adopt-build-farm.sh में शामिल कर सकते हैं जो मुझे विश्वास है कि बिल्ड पाइपलाइन द्वारा कहा जाता है?

Linux में jdk11u के लिए MB में स्थान लगभग 230MB और macOS और Windows के लिए लगभग 40MB है। Jdk8u में Linux के लिए लगभग 100MB और Windows के लिए 5MB है। Jdk16 के आकार काफी हद तक jdk11u के समान हैं।

@milderhc हाय, एक त्वरित प्रश्न, वर्तमान openj9 "-debug-image" और नए "-debug-symbols" के बीच क्या अंतर है?

openj9 "डीबग-छवि" एक ही बात नहीं है? https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/cf49ddabb9e46e90af63e85f03e3e1e71338f6a2/closed/DebugImage.gmk

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

हॉटस्पॉट को एक "डीबग-इमेज" भी कहना समझदारी होगी?

तो आकार पर कुछ मोटे तौर पर गणना:
प्रत्येक संस्करण के लिए कैश बनाने वाले प्लेटफ़ॉर्म:

• बांह: 5x230MB = +1.15Gb
• pLinux : 5x230MB = +1.15Gb

- मैक: 5x10MB = +50MB

प्लेटफ़ॉर्म जो वर्तमान में कैश नहीं करते हैं:
ऐक्स: डब्ल्यूएस क्लियर किया गया
zLinux: डब्ल्यूएस क्लियर किया गया
जीत: केवल कैश अंतिम निर्माण 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.3Gb अतिरिक्त वृद्धि जोड़ना

@sxa fyi

मैं खुद भी यही पूछ रहा था। मुझे लगता है कि वे वही हैं। वास्तव में, अगर हम --with-debug-symbols-package के साथ openj9 के लिए स्क्रिप्ट को कॉल करते हैं तो हमें दो पैकेज मिल सकते हैं। डिबग-प्रतीकों का नाम बदलकर डिबग-इमेज में बदलना समझ में आता है।

मैं खुद भी यही पूछ रहा था। मुझे लगता है कि वे वही हैं। वास्तव में, अगर हम --with-debug-symbols-package के साथ openj9 के लिए स्क्रिप्ट को कॉल करते हैं तो हमें दो पैकेज मिल सकते हैं। डिबग-प्रतीकों का नाम बदलकर डिबग-इमेज में बदलना समझ में आता है।

हाँ सहमत

मैं खुद भी यही पूछ रहा था। मुझे लगता है कि वे वही हैं। वास्तव में, अगर हम --with-debug-symbols-package के साथ openj9 के लिए स्क्रिप्ट को कॉल करते हैं तो हमें दो पैकेज मिल सकते हैं। डिबग-प्रतीकों का नाम बदलकर डिबग-इमेज में बदलना समझ में आता है।

इसलिए मुझे लगता है कि हमें तर्क को अद्यतन करने की आवश्यकता है, इसलिए ओपनज 9 के लिए यह वर्तमान "डीबग-इमेज" लक्ष्य का उपयोग करता है जैसा कि यह वर्तमान में करता है, और अन्य वेरिएंट के लिए आपके "डीबग-इमेज" बनाने के लिए आपके द्वारा जोड़े गए नए तर्क का उपयोग करता है।

ठीक है, मैं इसे पहले अपडेट कर दूंगा।

@milderhc हाय मिल्डर, यह कैसा चल रहा है?

@ एंड्रयू-एम-लियोनार्ड हाय, देर से उत्तर के लिए खेद है। मैंने पुल अनुरोध बनाया: https://github.com/AdoptOpenJDK/openjdk-build/pull/2393

@milderhc धन्यवाद, कि पीआर अच्छा लग रहा है। एक बार विलय हो जाने के बाद यह केवल एक बात है:

1. जेनकिंस इंफ्रास्ट्रक्चर क्षमता मूल्यांकन/प्रभाव निष्पादित करें: https://github.com/AdoptOpenJDK/openjdk-build/issues/2042#issuecomment -756665091
2. (1) पूरा करने के बाद, --create-debug-image if वैरिएंट != "openj9" को यहाँ कहीं भी जोड़ना: https://github.com/AdoptOpenJDK/openjdk-build/blob/102237341c7f0737f0dd4dc57fcc7e9e3ffe3bd5/build-farm/make-adopt -बिल्ड-फार्म.श#एल164

बिल्ड आउटपुट क्लीनिंग पीआर को अब मर्ज कर दिया गया है, और इसे प्रभावित करने के लिए बिल्ड नोड्स में प्रचारित करने की आवश्यकता है। वर्तमान में सबसे सीमांत स्थान के साथ बिल्ड नोड्स 2 आर्म नोड्स हैं, जिसमें अब तक क्रमशः 3Gb, 4Gb का अतिरिक्त स्थान है। इस समय इसे पेश करने से यह 2 मशीनें लगभग 1.2Gb से हाशिए पर आ जाएंगी।
एक बार क्लीन बिल्ड आउटपुट का प्रचार हो जाने के बाद मैं किसी भी बेकार उपयोग की जांच करने और नोड्स की निगरानी करने के लिए प्रत्येक की जांच करूंगा।

बिल्ड-स्केलवे-ubuntu1604-armv7-1 की जांच करने के बाद, बिल्ड आउटपुट सफाई को इससे 8Gb जारी करना चाहिए।

@sxa fyi

jdk8/11/16/17 . पर हाथ के लिए प्रस्तुत बिल्ड पाइपलाइन
नया आर्म नोड स्पेस:

• बिल्ड-स्केलवे-उबंटू1604-आर्मव7-1 : 18जीबी
• बिल्ड-स्केलवे-उबंटू1604-आर्मव7-2 : 19जीबी
  इसलिए हमने कम से कम 6Gb . खाली कर दिया है
  यह हमें आसानी से डिबग-छवियों के लिए पर्याप्त हेडरूम देता है।

@milderhc क्या आप --create-debug-image को सक्षम करने के लिए एक पीआर प्रस्तावित करना चाहेंगे?
https://github.com/AdoptOpenJDK/openjdk-build/blob/ecb4ce1182b079fb88cc77ce871e3ad1216e4612/build-farm/make-adopt-build-farm.sh#L163

धन्यवाद, @ एंड्रयू-एम-लियोनार्ड, क्या यह डीबग-छवियों को डाउनलोड करने योग्य होने के लिए पर्याप्त होगा?

यहाँ यह है: https://github.com/AdoptOpenJDK/openjdk-build/pull/2443

डिबग-इमेज के साथ हॉटस्पॉट के लिए नाइटली बिल्ड अब वेबसाइट से उपलब्ध हैं: https://adoptopenjdk.net/nightly.html?variant=openjdk8&jvmVariant=hotspot

इसके अलावा एपीआई के माध्यम से: 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_order=DEFAULT&ventordk

शेष चीजें:

• अपस्ट्रीम मैक डीबग jdk8 पैच
• अपस्ट्रीम जीत डिबग jdk8 फिक्स
• सभी संस्करणों के लिए अपस्ट्रीम AIX डिबग फिक्स