🗒️ 🔆 🛡️ GraalVM संकलक अनुकूलन के हुड के नीचे क्या है? 🙍🏾 🏇🏾 💃🏼

हम GraalVM के काम से निपटना जारी रखते हैं, और इस बार हमारे पास लेख का एक अनुवाद है जिसका नाम है Aleksandar Prokopec "अंडर द हुड ऑफ ग्रेवलम JIT ऑप्टिमाइज़ेशन", जो मूल रूप से ब्लॉग पर प्रकाशित हुआ है। लेख में कुछ दिलचस्प लिंक हैं, बाद में हम इन लेखों का अनुवाद करने की कोशिश करेंगे।

पिछली बार मीडियम पर, हमने जावा हॉटस्पॉट वीएम की तुलना में ग्रेवलम पर जावा स्ट्रीम एपीआई के प्रदर्शन के मुद्दों को देखा। GraalVM को उच्च प्रदर्शन की विशेषता है, और उन प्रयोगों में हमने 1.7 से 5 बार त्वरण प्राप्त किया। बेशक, प्रदर्शन लाभ के विशिष्ट मूल्य हमेशा आपके द्वारा चलाए जाने वाले कोड और लोड डेटा पर निर्भर करेंगे, इसलिए इससे पहले कि आप कोई निष्कर्ष निकालें, आपको अपने कोड को खुद GraalVM पर चलाने का प्रयास करना चाहिए।

इस लेख में, हम GraalVM के इनसाइड में गहराई से जाएंगे और देखेंगे कि JIT संकलन कैसे होता है।

ग्रेवालम में जेआईटी अनुकूलन

आइए कई उच्च-स्तरीय ऑप्टिमाइज़ेशनों पर एक नज़र डालें, जो ग्रेवालम संकलक उपयोग करता है। इस लेख में हम केवल उनके काम के विशिष्ट उदाहरणों के साथ सबसे दिलचस्प अनुकूलन पर स्पर्श करेंगे। यदि आप गहरी खुदाई करना चाहते हैं, तो GraalVM संकलक अनुकूलन का एक अच्छा अवलोकन कार्य में है "आक्रामक JIT संकलन के साथ संग्रह संचालन को इष्टतम बनाने" ।

इनलाइनिंग

यदि आप समय-समय पर विधानसभा को नहीं छूते हैं, तो आधुनिक वर्चुअल मशीनों में अधिकांश जेआईटी कंपाइलर्स इन-हाउस विश्लेषण करते हैं। इसका मतलब यह है कि प्रत्येक विशेष क्षण में एक विधि का विश्लेषण होता है। इस कारण से, इंट्राप्रोसेरेडुरल विश्लेषण पूरे कार्यक्रम के इंटरप्रोसेरुरल विश्लेषण की तुलना में बहुत तेज है, जो आमतौर पर जेआईटी कंपाइलर के काम के लिए आवंटित समय में पूरा करने का समय नहीं होता है। एक संकलक में जो इंट्रा-प्रक्रियात्मक अनुकूलन का उपयोग करता है (उदाहरण के लिए, एक समय में एक विधि का अनुकूलन), सबसे महत्वपूर्ण मूलभूत अनुकूलन में से एक है। Inlining महत्वपूर्ण है क्योंकि यह प्रभावी रूप से विधि को बढ़ाता है, जिसका अर्थ है कि संकलक एक साथ कोड के कई टुकड़ों को अनुकूलित करने के लिए अधिक अवसर देख सकता है जो प्रतीत होता है असंबंधित तरीकों में उपयोग किया जाता है।

उदाहरण के लिए, पिछले लेख से volleyballStars विधि को लें:

 @Benchmark public double volleyballStars() { return Arrays.stream(people) .map(p -> new Person(p.hair, p.age + 1, p.height)) .filter(p -> p.height > 198) .filter(p -> p.age >= 18 && p.age <= 21) .mapToInt(p -> p.age) .average().getAsDouble(); }

इस आरेख में, हम इस पद्धति के मध्यवर्ती प्रतिनिधित्व (IR) के कुछ हिस्सों को ग्रैल्वीएम में देखते हैं, फिलहाल इसी जावा बाइटकोड के पार्सिंग के तुरंत बाद।

आप इस आईआर के बारे में सोच सकते हैं कि स्टेरॉयड पर कुछ प्रकार के अमूर्त वाक्यविन्यास पेड़ - इसके लिए धन्यवाद, कुछ अनुकूलन प्रदर्शन करना आसान है। इससे कोई फर्क नहीं पड़ता कि यह IR कैसे काम करता है, लेकिन यदि आप इस विषय को अधिक गहराई से समझना चाहते हैं, तो आप "Graal IR: एक एक्स्टेंसिबल डिक्लेरेटिव इंटरमीडिएट रिप्रेजेंटेशन" नामक दस्तावेज़ को देख सकते हैं।

यहां मुख्य निष्कर्ष यह है कि ग्राफ के पीले नोड्स द्वारा इंगित विधि का नियंत्रण प्रवाह और लाल रेखाएं क्रमिक रूप से Stream इंटरफ़ेस के तरीकों को निष्पादित करती हैं: Stream.filter , Stream.mapToInt , IntStream.average । इन विधियों के कोड में क्या है, इसके बारे में सटीक जानकारी का अभाव, संकलक विधि को सरल बनाने में सक्षम नहीं है - और यहां इनलाइनिंग बचाव के लिए आती है!

इनलाइनिंग नामक एक परिवर्तन एक बहुत ही समझ में आने वाली बात है: यह सिर्फ कॉल करने के लिए स्थानों की तलाश करता है और उन्हें इसी इनलाइन विधि के शरीर के साथ प्रतिस्थापित करता है, उन्हें अंदर एम्बेड करता है। आइए तरीकों के भाग को इनलाइन करने के बाद वॉलीबॉलस्टार विधि के आईआर पर एक नज़र डालें। केवल वह भाग जो IntStream.average कॉल का अनुसरण करता है, IntStream.average :

आरेख दिखाता है कि getAsDouble (नोड नंबर 71) पर कॉल आईआर से गायब हो गई है। ध्यान दें कि getAsDouble ऑब्जेक्ट का getAsDouble विधि IntStream.average ( volleyballStars IntStream.average विधि में अंतिम कॉल) से IntStream.average में परिभाषित किया गया है:

 public double getAsDouble() { if (!isPresent) { throw new NoSuchElementException("No value present"); } return value; }

यहां हम isPresent फ़ील्ड (नोड नंबर 190, LoadField ) की LoadField और value फ़ील्ड को पढ़ सकते हैं। हालाँकि, NoSuchElementException अपवाद के कोई निशान नहीं NoSuchElementException हैं, और कोई और कोड नहीं है जो इसे फेंकता है।

इसका कारण यह है कि GraalVM संकलक अनुमान लगाता है: वॉलीबॉलस्टार विधि कभी भी अपवाद नहीं फेंकेगी। यह ज्ञान आमतौर पर getAsDouble संकलन के दौरान उपलब्ध नहीं है - इसे कार्यक्रम में कई अलग-अलग स्थानों से बुलाया जा सकता है, और कुछ अन्य मामलों में अपवाद अभी भी काम करेगा। हालांकि, एक विशेष वॉलीबॉल स्टार्स विधि में, एक अपवाद होने की संभावना नहीं है क्योंकि संभावित वॉलीबॉल सितारों का सेट कभी खाली नहीं होता है। इस कारण से, GraalVM शाखा को हटा देता है और FixedGuard सम्मिलित करता है - एक नोड जो हमारी धारणा के उल्लंघन के मामले में कोड का अनुकूलन करता है। यह एक काफी न्यूनतर उदाहरण है, और वास्तविक जीवन में बहुत अधिक जटिल मामले हैं कि इनलाइनिंग अन्य अनुकूलन को कैसे मदद करता है।

हम जानते हैं कि प्रोग्राम कॉल ट्री आमतौर पर बहुत गहरा होता है या शायद अंतहीन भी। तो, कुछ बिंदु पर इनलाइनिंग को रोकने की आवश्यकता है - इसमें ऑपरेटिंग समय और मेमोरी आकार पर बहुत विशिष्ट प्रतिबंध हैं। यह जानते हुए, यह स्पष्ट हो जाता है: इनलाइन क्या और कब निर्धारित करना बहुत मुश्किल है।

पॉलिमॉर्फिक इनलाइनिंग

इनलाइनिंग केवल तभी काम करती है जब कंपाइलर उस विशिष्ट विधि को निर्धारित कर सकता है जो विधि कॉल ऑपरेशन का उद्देश्य है। लेकिन जावा में, आमतौर पर उन तरीकों के लिए कई अप्रत्यक्ष कॉल होते हैं जिनके कार्यान्वयन स्टैटिक्स में अज्ञात होते हैं, जिन्हें वर्चुअल वॉच का उपयोग करके रनटाइम में खोजा जाता है।

उदाहरण के लिए, IntStream.average पद्धति को लें। इसका विशिष्ट कार्यान्वयन इस तरह दिखता है:

 @Override public final OptionalDouble average() { long[] avg = collect( () -> new long[2], (ll, i) -> { ll[0]++; ll[1] += i; }, (ll, rr) -> { ll[0] += rr[0]; ll[1] += rr[1]; }); return avg[0] > 0 ? OptionalDouble.of((double) avg[1] / avg[0]) : OptionalDouble.empty(); }

कोड की स्पष्ट सादगी को मूर्ख मत बनने दो! इस पद्धति को collect कॉल के संदर्भ में परिभाषित किया गया है, और जादू यहां होता है। इस पद्धति का कॉल ट्री (उदाहरण के लिए, कॉल पदानुक्रम) तेजी से बढ़ता है क्योंकि हम collect में गहराई से गिरते collect । इस चित्र को देखें:

कॉल ट्री को ट्रेस करने की प्रक्रिया में कुछ बिंदु से शुरू, इनलाइनर जावा opWrapSink फ्रेमवर्क से opWrapSink कॉल के खिलाफ टिकी हुई है, जो एक सार विधि है:

 abstract<P_IN> Sink<P_IN> wrapSink(Sink<P_OUT> sink);

आमतौर पर एक इनलाइनर आगे नहीं जाएगा, क्योंकि यह एक अप्रत्यक्ष कॉल है। एक विशिष्ट विधि का निर्धारण केवल कार्यक्रम के निष्पादन के दौरान होगा, और अब जड़नाकार को यह नहीं पता है कि वह क्या काम करना जारी रखेगा।

GraalVM के मामले में, कुछ और होता है: यह प्रत्येक अप्रत्यक्ष डायल पीयर के लिए लक्ष्य विधि का एक प्रकार प्रोफ़ाइल बचाता है। यह प्रोफ़ाइल अनिवार्य रूप से सिर्फ एक तालिका है जो बताती है कि wrapSink प्रत्येक कार्यान्वयन को कितनी बार wrapSink गया था। हमारे मामले में, प्रोफ़ाइल अनाम कक्षाओं में तीन अलग-अलग कार्यान्वयनों के बारे में जानती है: ReferencePipeline$2 , ReferencePipeline$3 , ReferencePipeline$4 । ये कार्यान्वयन क्रमशः 50%, 25% और 25% की संभावना के साथ कहा जाता है।

 0.500000: Ljava/util/stream/ReferencePipeline$2; 0.250000: Ljava/util/stream/ReferencePipeline$4; 0.250000: Ljava/util/stream/ReferencePipeline$3; notRecorded: 0.000000

यह जानकारी संकलक को अमूल्य सहायता प्रदान करती है, जिससे आपको टाइपस्विच उत्पन्न करने की अनुमति मिलती है - एक छोटा switch जो रनटाइम में विधि के प्रकार की जांच करता है, फिर उपरोक्त मामलों में से प्रत्येक के लिए एक विशिष्ट विधि कहता है। नीचे दी गई छवि मध्यवर्ती दृश्य का एक हिस्सा दिखाती है जिसमें टाइपविच (तीन if नोड्स) दिखा रहा है, if यह देखने के लिए कि प्राप्तकर्ता प्रकार ReferencePipeline$2 , ReferencePipeline$3 या ReferencePipeline$4 । प्रत्येक InstanceOf चेक के सफल ब्रांचिंग में प्रत्येक डायरेक्ट कॉल अब इनलाइन हो सकती है या इसमें कुछ अतिरिक्त अनुकूलन जोड़ सकते हैं। यदि कोई भी प्रकार परीक्षण पास नहीं करता है, तो कोड को Deopt नोड में बंद कर दिया Deopt है (एक विकल्प के रूप में, आप वर्चुअल प्रेषण चला सकते हैं)।

यदि आप बहुरूपता को और अधिक गहराई से समझना चाहते हैं, तो मैं इस विषय पर क्लासिक काम करने की सलाह देता हूं, "इनलाइनिंग ऑफ वर्चुअल मैथड्स" ।

आंशिक पलायन विश्लेषण

आइए अपने वॉलीबॉल उदाहरण पर वापस जाएं। ध्यान दें कि लैम्बडा के अंदर आबंटित Person वस्तुओं में से कोई भी map कार्य के लिए पास नहीं किया गया है, volleyballStars विधि के दायरे से बच जाता है। दूसरे शब्दों में, जिस समय volleyballStars विधि समाप्त होती है, स्मृति का ऐसा कोई क्षेत्र नहीं होता है, जो टाइप Person की वस्तुओं की ओर इंगित करता हो। विशेष रूप से, getHeight मान का रिकॉर्ड केवल ऊंचाई फ़िल्टरिंग के लिए उपयोग किया जाता है।

volleyballStars विधि के संकलन के दौरान कुछ बिंदु पर, हम नीचे दिए गए चित्र में दिखाए गए आईआर पर आते हैं। आरंभिक नोड -1621 से शुरू होने वाला ब्लॉक Person ऑब्जेक्ट ( Alloc नोड में) के आवंटन के साथ शुरू होता है, जिसे 1 के वेतन वृद्धि के साथ age क्षेत्र के मूल्य और height क्षेत्र के पिछले मूल्य दोनों के साथ आरम्भ किया जाता है। height फ़ील्ड को पहले LoadField -1539 नोड में पढ़ा जाता है। आवंटन का परिणाम AllocatedObject -2137 में समझाया गया है और accept -1625 विधि कॉल के लिए भेजा गया है। कंपाइलर इस समय और कुछ नहीं कर सकता है - उसके दृष्टिकोण से, ऑब्जेक्ट volleyballStars विधि से बच गया। ( अनुवादक का ध्यान दें: "भागकर किसी वस्तु" को अंग्रेजी में "एस्केप" कहा जाता है, इसलिए अनुकूलन का नाम "एस्केप एनालिसिस" है ।

उसके बाद, संकलक accept कॉल को इनलाइन करने का निर्णय लेता है - यह उचित लगता है। परिणामस्वरूप, हम निम्नलिखित IR पर आते हैं:

और यहां जेआईटी कंपाइलर आंशिक रूप से भागने का विश्लेषण शुरू करता है: यह नोटिस करता है कि AllocatedObject उपयोग केवल height क्षेत्र को पढ़ने के लिए किया जाता है (याद रखें, height उपयोग केवल फ़िल्टरिंग स्थिति में किया जाता है, जांचें कि ऊंचाई 198 से अधिक है)। इसलिए, कंपाइलर height -2167 फ़ील्ड के रीडिंग को पुन: असाइन कर सकता है ताकि सीधे नोड के साथ काम कर सके जो पहले Person ऑब्जेक्ट ( Alloc -2136 नोड) को लिखा गया है, और यह हमारा LoadField -1539 है। इसके अलावा, इसके बाद Alloc नोड किसी अन्य नोड के इनपुट पर नहीं जाता है, इसलिए आप बस इसे हटा सकते हैं - यह मृत कोड है!

यह अनुकूलन, वास्तव में, मुख्य कारण है कि वॉलीबॉलस्टार का उदाहरण ग्रेवालम पर स्विच करने के बाद पांच गुना त्वरण का अनुभव हुआ। भले ही सभी Person वस्तुओं की जरूरत नहीं है और निर्माण के तुरंत बाद त्याग दिया जाता है, फिर भी उन्हें ढेर पर आवंटित करने की आवश्यकता है, उनकी स्मृति को अभी भी आरंभ करने की आवश्यकता है। आंशिक रूप से भागने का विश्लेषण आपको आवंटन को खत्म करने या उन्हें उन कोड शाखाओं में स्थानांतरित करने की अनुमति देता है जहां ऑब्जेक्ट वास्तव में भाग जाते हैं और जो अक्सर कम होते हैं।

आप आंशिक पलायन विश्लेषण और जावा के लिए स्केलर रिप्लेसमेंट नामक पेपर में आंशिक पलायन विश्लेषण की गहरी समझ प्राप्त कर सकते हैं।

परिणाम

इस लेख में, हमने तीन GraalVM ऑप्टिमाइज़ेशन को देखा: इनलाइनिंग, पॉलीमॉर्फिक इनलाइनिंग और आंशिक रूप से भागने का विश्लेषण। कई और अलग-अलग अनुकूलन हैं: चक्रों का प्रचार और विभाजन, रास्तों का दोहराव, वैश्विक मूल्यों की संख्या, स्थिरांक का दृढ़ीकरण, मृत कोड को हटाना, सट्टा निष्पादन और इसी तरह।

यदि आप अधिक जानना चाहते हैं कि GraalVM कैसे काम करता है, तो प्रकाशन पृष्ठ खोलने में संकोच न करें। यदि आप स्वयं सुनिश्चित करना चाहते हैं कि क्या ग्रेवालम आपके कोड को गति दे सकता है, तो आप बायनेरिज़ डाउनलोड कर सकते हैं और इसे स्वयं आज़मा सकते हैं।

अनुवादक से: अतिरिक्त सामग्री

सम्मेलनों में, JPoint और जोकर अक्सर GraalVM के बारे में बात करते हैं। उदाहरण के लिए, पिछले JPoint 2019 में, थॉमस वुएर्थिंगर (ओरेकल लैब्स में रिसर्च डायरेक्टर, ग्रेवालम के लिए जिम्मेदार) और ओलेग शेल्लाव, दो आधिकारिक प्रौद्योगिकी इंजीलवादियों में से एक, ने हमसे मुलाकात की।

आप इन और अन्य वीडियो को हमारे YouTube चैनल पर देख सकते हैं:

हम आपको याद दिलाते हैं कि अगले जेपोट को मास्को में 15-16 मई, 2020 को आयोजित किया जाएगा और आधिकारिक वेबसाइट पर पहले से ही टिकट खरीदे जा सकते हैं।

GraalVM संकलक अनुकूलन के हुड के नीचे क्या है?