JVM में संकलन प्रकार: एक्सपोज़िंग ब्लैक मैजिक सत्र

सभी को नमस्कार!

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

अच्छा पढ़ लो!

मेरा मानना ​​है कि जिसने कभी जावा में प्रोग्राम किया है उसने तत्काल संकलन (जेआईटी) के बारे में सुना है, और संभवतः निष्पादन (एओटी) से पहले संकलन। इसके अलावा, यह व्याख्या करने की कोई ज़रूरत नहीं है कि "व्याख्या की गई" भाषाएं क्या हैं। यह आलेख बताएगा कि जावा वर्चुअल मशीन, जेवीएम में इन सभी सुविधाओं को कैसे लागू किया जाता है।

आप शायद जानते हैं कि जावा में प्रोग्रामिंग करते समय, आपको एक कंपाइलर ("जेवाक" प्रोग्राम का उपयोग करके) चलाने की आवश्यकता होती है, जो जावा स्रोत कोड (। जावा फाइलों) को जावा बाइटकोड (.क्लास फाइलों) में एकत्रित करता है। जावा बाइटकोड एक मध्यवर्ती भाषा है। इसे "मध्यवर्ती" कहा जाता है क्योंकि यह एक वास्तविक कंप्यूटिंग डिवाइस (सीपीयू) द्वारा समझ में नहीं आता है और इसे कंप्यूटर द्वारा निष्पादित नहीं किया जा सकता है और इस प्रकार, स्रोत कोड और प्रोसेसर में निष्पादित "मूल" मशीन कोड के बीच एक संक्रमणकालीन रूप का प्रतिनिधित्व करता है।

किसी भी विशिष्ट कार्य को करने के लिए जावा बाइटकोड के लिए, इसे करने के लिए 3 तरीके हैं:

1. मध्यवर्ती कोड को सीधे निष्पादित करें। यह कहना बेहतर है कि इसे "व्याख्या" करने की आवश्यकता है। JVM में जावा दुभाषिया है। जैसा कि आप जानते हैं, जेवीएम को काम करने के लिए, आपको "जावा" प्रोग्राम चलाने की आवश्यकता है।
2. मध्यवर्ती कोड को निष्पादित करने से ठीक पहले, इसे मूल कोड में संकलित करें और सीपीयू को इस ताज़ा बेक्ड मूल कोड को निष्पादित करने के लिए मजबूर करें। इस प्रकार, निष्पादन से ठीक पहले संकलन होता है (बस समय में) और इसे "गतिशील" कहा जाता है।
3. 3 बहुत ही पहली बात, प्रोग्राम लॉन्च होने से पहले, मध्यवर्ती कोड को मूल में अनुवादित किया जाता है और इसे शुरू से अंत तक सीपीयू के माध्यम से चलाया जाता है। यह संकलन निष्पादन से पहले किया जाता है और इसे एओटी (समय से आगे) कहा जाता है।

तो, (1) दुभाषिया का काम है, (2) JIT संकलन का परिणाम है, और (3) AOT संकलन का परिणाम है।

पूर्णता के लिए, मैं उल्लेख करूंगा कि एक चौथा दृष्टिकोण है - सीधे स्रोत कोड की व्याख्या करने के लिए, लेकिन जावा में यह स्वीकार नहीं किया जाता है। यह किया जाता है, उदाहरण के लिए, पायथन में।
अब देखते हैं कि "जावा" (1) जेआईटी कंपाइलर और / या (3) एओटी कंपाइलर - (कब) के इंटरप्रेटर के रूप में काम करता है।

संक्षेप में - एक नियम के रूप में, "जावा" दोनों (1) और (2) करता है। जावा 9 से शुरू करना, एक तीसरा विकल्प भी संभव है।

यहां हमारी Test क्लास है, जिसका उपयोग भविष्य के उदाहरणों में किया जाएगा।

 public class Test { public int f() throws Exception { int a = 5; return a; } public static void main(String[] args) throws Exception { for (int i = 1; i <= 10; i++) { System.out.println("call " + Integer.valueOf(i)); long a = System.nanoTime(); new Test().f(); long b = System.nanoTime(); System.out.println("elapsed= " + (ba)); } } } 

जैसा कि आप देख सकते हैं, एक main विधि है जो Test ऑब्जेक्ट को तुरंत करती है और एक पंक्ति में 10 बार f फ़ंक्शन को चक्रीय रूप से कॉल करती है। f फ़ंक्शन लगभग कुछ भी नहीं करता है।

इसलिए, यदि आप उपरोक्त कोड को संकलित करते हैं और चलाते हैं, तो आउटपुट काफी अपेक्षित होगा (बेशक, बीता हुआ समय आपके लिए अलग हो जाएगा):

 call 1 elapsed= 5373 call 2 elapsed= 913 call 3 elapsed= 654 call 4 elapsed= 623 call 5 elapsed= 680 call 6 elapsed= 710 call 7 elapsed= 728 call 8 elapsed= 699 call 9 elapsed= 853 call 10 elapsed= 645 

और अब सवाल यह है: क्या यह निष्कर्ष एक व्याख्याता के रूप में "जावा" के कार्य का परिणाम है, अर्थात, विकल्प (1), "जावा" एक जेआईटी संकलक के रूप में, विकल्प (2) है या यह किसी तरह एओटी संकलन से संबंधित है , वह है, विकल्प (3)? इस लेख में मैं इन सभी सवालों के सही जवाब खोजने जा रहा हूं।

पहला उत्तर जो मैं देना चाहता हूं वह सबसे अधिक संभावना है कि केवल (1) यहां होता है। मैं कहता हूं कि "सबसे अधिक संभावना है", क्योंकि मुझे नहीं पता कि क्या कोई पर्यावरण चर यहां सेट किया गया है जो डिफ़ॉल्ट जेवीएम विकल्पों को बदल देगा। यदि कुछ भी अतिश्योक्तिपूर्ण स्थापित नहीं है, और यह है कि "जावा" डिफ़ॉल्ट रूप से कैसे काम करता है, तो यहां हम 100% देख रहे हैं बस विकल्प (1), यानी कोड पूरी तरह से व्याख्या किया गया है। मुझे इस पर यकीन है, क्योंकि:

• जावा प्रलेखन के अनुसार, -XX:CompileThreshold=invocations विकल्प को डिफ़ॉल्ट -XX:CompileThreshold=invocations क्लाइंट JVM पर invocations=1500 (नीचे वर्णित क्लाइंट JVM पर अधिक) के साथ शुरू किया गया है। चूंकि मैं इसे केवल 10 बार चलाता हूं, और 10 <1500, हम यहां गतिशील संकलन के बारे में बात नहीं कर रहे हैं। आमतौर पर, यह कमांड लाइन विकल्प निर्दिष्ट करता है कि गतिशील संकलन कदम शुरू होने से पहले फ़ंक्शन को कितनी बार (अधिकतम) व्याख्या की जानी चाहिए। मैं इसके नीचे निवास करूंगा।
• वास्तव में, मैंने इस कोड को नैदानिक ​​झंडे के साथ चलाया, इसलिए मुझे पता है कि क्या यह गतिशील रूप से संकलित था। मैं नीचे इस बिंदु को भी समझाऊंगा।

कृपया ध्यान दें: जेवीएम क्लाइंट या सर्वर मोड में काम कर सकता है, और पहले और दूसरे मामलों में डिफ़ॉल्ट रूप से सेट किए गए विकल्प अलग होंगे। एक नियम के रूप में, स्टार्टअप मोड के बारे में निर्णय पर्यावरण या कंप्यूटर पर निर्भर करता है, जहां जेवीएम लॉन्च किया गया था। इसके बाद, मैं सभी –client दौरान –client विकल्प निर्दिष्ट करूंगा, ताकि यह संदेह न हो कि प्रोग्राम क्लाइंट मोड में चल रहा है। यह विकल्प उन पहलुओं को प्रभावित नहीं करेगा जिन्हें मैं इस पोस्ट में प्रदर्शित करना चाहता हूं।

यदि आप "java" को -XX:PrintCompilation , तो प्रोग्राम गतिशील रूप से संकलित होने पर एक लाइन प्रिंट करेगा। यह मत भूलो कि प्रत्येक फ़ंक्शन के लिए जेआईटी संकलन अलग से किया जाता है, क्लास में कुछ फ़ंक्शन बायटेकोड (जो संकलित नहीं हैं) में बने रह सकते हैं, जबकि अन्य पहले से ही जेआईटी संकलन पास कर सकते हैं, अर्थात प्रोसेसर में सीधे निष्पादन के लिए तैयार। ।

नीचे मैं -Xbatch विकल्प भी जोड़ता हूं। -Xbatch विकल्प -Xbatch जरूरत केवल आउटपुट को अधिक प्रस्तुत करने के लिए है; अन्यथा, JIT संकलन प्रतिस्पर्धात्मक रूप से (व्याख्या के साथ) आगे बढ़ता है, और संकलन के बाद आउटपुट कभी-कभी रनटाइम ( -XX:PrintCompilation कारण) पर अजीब लग सकता है। हालाँकि, –Xbatch विकल्प पृष्ठभूमि संकलन को अक्षम करता है, इसलिए, JIT संकलन को निष्पादित करने से पहले, हमारे कार्यक्रम का निष्पादन रोक दिया जाएगा।

(पठनीयता के लिए, मैं एक नई पंक्ति से प्रत्येक विकल्प लिखूंगा)

 $ java -client -Xbatch -XX:+PrintCompilation Test 

मैं यहां इस कमांड का आउटपुट नहीं डालूंगा, क्योंकि डिफ़ॉल्ट रूप से JVM बहुत सारे आंतरिक कार्यों (उदाहरण के लिए, जावा, सूरज, jdk पैकेजों से संबंधित) को संकलित करता है, इसलिए आउटपुट बहुत लंबा होगा - इसलिए, मेरी स्क्रीन पर, आंतरिक कार्यों पर 274 लाइनें हैं , और कुछ और - कार्यक्रम के बहुत निष्कर्ष तक)। इस शोध को आसान बनाने के लिए, मैं आंतरिक कक्षाओं के लिए JIT संकलन को रद्द कर दूंगा या चुनिंदा रूप से इसे केवल अपने तरीके ( Test.f ) के लिए सक्षम Test.f । ऐसा करने के लिए, एक और विकल्प निर्दिष्ट करें, -XX:CompileCommand । आप कई कमांड (संकलन) निर्दिष्ट कर सकते हैं, इसलिए उन्हें अलग फाइल में रखना आसान होगा। सौभाग्य से, हमारे पास -XX:CompileCommandFile विकल्प है -XX:CompileCommandFile । इसलिए, फ़ाइल बनाने के लिए आगे बढ़ें। मैं इसे hotspot_compiler इस कारण से hotspot_compiler कि मैं शीघ्र ही hotspot_compiler और निम्नलिखित लिखूंगा:

 quiet exclude java/* * exclude jdk/* * exclude sun/* * 

इस मामले में, यह पूरी तरह से स्पष्ट होना चाहिए कि हम सभी पैकेजों में सभी कार्यों (अंतिम *) को सभी पैकेजों से बाहर करते हैं जो जावा, जेडडी और सूरज से शुरू होते हैं (पैकेज के नाम / से अलग होते हैं, और आप * का उपयोग कर सकते हैं)। quiet कमांड JVM को बताता है कि अपवर्जित वर्गों के बारे में कुछ भी नहीं लिखा जाए, इसलिए केवल जो अब संकलित हैं वे कंसोल पर आउटपुट होंगे। तो, मैं चलाता हूं:

 java -client -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler Test 

इस कमांड के आउटपुट के बारे में बताने से पहले, मैं आपको याद दिलाता हूं कि मैंने इस फाइल का नाम hotspot_compiler रखा है, क्योंकि ऐसा लगता है (मैंने चेक नहीं किया था) कि Oracle JDK में .hotspot_compiler नाम कंपाइलर कमांड के लिए फाइल के लिए डिफ़ॉल्ट रूप से सेट है।

तो निष्कर्ष यह है:

 many lines like this 111 1 n 0 java.lang.invoke.MethodHandle::linkToStatic(LLLLLL)L (native) (static) call 1 some more lines like this 161 48 n 0 java.lang.invoke.MethodHandle::linkToStatic(ILIJL)I (native) (static) elapsed= 7558 call 2 elapsed= 1532 call 3 elapsed= 920 call 4 elapsed= 732 call 5 elapsed= 774 call 6 elapsed= 815 call 7 elapsed= 767 call 8 elapsed= 765 call 9 elapsed= 757 call 10 elapsed= 868 

सबसे पहले, मुझे नहीं पता कि कुछ java.lang.invoke.MethodHandler. विधियां अभी भी क्यों संकलित हैं java.lang.invoke.MethodHandler. शायद, कुछ चीजों को बंद नहीं किया जा सकता है। जैसा कि मैंने समझा कि क्या बात है, मैं इस पोस्ट को अपडेट करूंगा। हालाँकि, जैसा कि आप देख सकते हैं, अन्य सभी संकलन चरण (पहले 274 लाइनें थीं) अब गायब हो गए हैं। आगे के उदाहरणों में, मैं java.lang.invoke.MethodHandler को संकलन लॉग के आउटपुट से भी हटा दूंगा।

देखते हैं कि हम क्या करने आए हैं। अब हमारे पास एक सरल कोड है जहां हम 10 बार अपना फ़ंक्शन चलाते हैं। मैंने पहले उल्लेख किया है कि इस फ़ंक्शन की व्याख्या की गई है, संकलित नहीं की गई है, जैसा कि दस्तावेज में इंगित किया गया है, और अब हम इसे लॉग में देखते हैं (उसी समय, हम इसे संकलन लॉग में नहीं देखते हैं, और इसका मतलब है कि यह जेआईटी संकलन के अधीन नहीं है)। ठीक है, आपने सिर्फ "जावा" उपकरण को कार्रवाई में देखा, व्याख्या की और केवल 100% मामलों में हमारे कार्य की व्याख्या की। तो, हम उस बॉक्स की जांच कर सकते हैं जो विकल्प (1) के साथ लगा है। हम (2), गतिशील संकलन पास करते हैं।

प्रलेखन के अनुसार, आप फ़ंक्शन को 1,500 बार चला सकते हैं और सुनिश्चित कर सकते हैं कि वास्तव में जेआईटी संकलन हो रहा है। हालाँकि, आप -XX:CompileThreshold=invocations कॉल -XX:CompileThreshold=invocations का भी उपयोग कर सकते हैं -XX:CompileThreshold=invocations , 1500 के बजाय वांछित मान सेट करें। आइए हम यहां पर 5. इसका मतलब है कि हम निम्नलिखित की उम्मीद करते हैं: हमारे फ़ंक्शन च के 5 "व्याख्या" के बाद, जेवीएम को विधि को संकलित करना होगा, और फिर संकलित संस्करण चलाना होगा।
java -client -Xbatch

 -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler -XX:CompileThreshold=5 Test 

यदि आप इस कमांड को चलाते हैं, तो आपने देखा होगा कि उपरोक्त उदाहरण की तुलना में कुछ भी नहीं बदला है। यही है, संकलन अभी भी नहीं होता है। प्रलेखन के अनुसार, यह पता चला है, -XX:CompileThreshold केवल तब काम करता है जब TieredCompilation अक्षम होता है, जो डिफ़ॉल्ट है। यह इस तरह से -XX:-TieredCompilation : -XX:-TieredCompilation । टिवर्ड कंपटीशन जावा 7 में लॉन्च की गई एक सुविधा है जो जेवीएम की लॉन्चिंग और क्रूज़िंग गति दोनों में सुधार करती है। इस पोस्ट के संदर्भ में, यह महत्वपूर्ण नहीं है, इसलिए इसे अक्षम करने के लिए स्वतंत्र महसूस करें। चलिए अब इस कमांड को फिर से चलाते हैं:

 java -client -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler -XX:CompileThreshold=5 -XX:-TieredCompilation Test 

यहाँ आउटपुट है (मुझे याद है, मैंने java.lang.invoke.MethodHandle बारे में लाइनें याद की java.lang.invoke.MethodHandle ):

 call 1 elapsed= 9411 call 2 elapsed= 1291 call 3 elapsed= 862 call 4 elapsed= 1023 call 5 227 56 b Test::<init> (5 bytes) 228 57 b Test::f (4 bytes) elapsed= 1051739 call 6 elapsed= 18516 call 7 elapsed= 940 call 8 elapsed= 769 call 9 elapsed= 855 call 10 elapsed= 838 

हम स्वागत करते हैं (हैलो!) गतिशील रूप से संकलित फ़ंक्शन Test.f या Test::<init> नंबर 5 पर कॉल करने के तुरंत बाद, क्योंकि मैंने CompileThreshold को 5 पर सेट किया है। JVM 5 बार फ़ंक्शन की व्याख्या करता है, फिर इसे संकलित करता है और अंत में संकलित संस्करण चलाता है। चूंकि फ़ंक्शन संकलित है, इसलिए इसे तेज़ी से चलना चाहिए, लेकिन हम इसे यहां सत्यापित नहीं कर सकते, क्योंकि यह फ़ंक्शन कुछ भी नहीं करता है। मुझे लगता है कि एक अलग पोस्ट के लिए यह एक अच्छा विषय है।

जैसा कि आप शायद पहले से ही अनुमान लगा चुके हैं, एक और समारोह यहाँ संकलित है, जिसका नाम है Test::<init> , जो Test क्लास का एक निर्माता है। चूँकि कोड कंस्ट्रक्टर (नए Test() ) को कॉल करता है, जब भी f कॉल किया जाता है, यह f फंक्शन के साथ एक साथ कम्पाइल करता है, ठीक 5 कॉल के बाद।

सिद्धांत रूप में, यह विकल्प (2), जेआईटी संकलन की चर्चा को समाप्त कर सकता है। जैसा कि आप देख सकते हैं, इस मामले में, फ़ंक्शन को पहले जेवीएम द्वारा व्याख्या किया गया है, फिर पांच गुना व्याख्या के बाद गतिशील रूप से संकलित किया गया है। मैं JIT संकलन के संबंध में अंतिम विवरण जोड़ना चाहूंगा, जिसका नाम विकल्प -XX:+PrintAssembly । जैसा कि नाम का अर्थ है, यह कंसोल को फ़ंक्शन के संकलित संस्करण (संकलित संस्करण = देशी मशीन कोड = कोडांतरक कोड) के लिए आउटपुट करता है। हालाँकि, यह केवल तभी काम करेगा जब लाइब्रेरी पथ में कोई डिस्सेम्बलर हो। मुझे लगता है कि डिस्सेम्बलर अलग-अलग जेवीएम में भिन्न हो सकता है, लेकिन इस मामले में हम hsdis के साथ काम कर रहे हैं - ओपनजेडक के लिए एक डिस्सेम्बलर। Hsdis लाइब्रेरी का सोर्स कोड या इसकी बाइनरी फाइल अलग-अलग जगहों पर ली जा सकती है। इस मामले में, मैंने इस फाइल को संकलित किया और JAVA_HOME/lib/server में hsdis-amd64.so डाला।

तो अब हम इस कमांड को निष्पादित कर सकते हैं। लेकिन पहले मुझे इसे चलाने के लिए जोड़ना होगा -XX:+PrintAssembly भी -XX:+UnlockDiagnosticVMOptions जोड़ने की जरूरत है -XX:+UnlockDiagnosticVMOptions , और इसे PrintAssembly विकल्प से पहले पालन करना होगा। यदि ऐसा नहीं किया जाता है, तो JVM आपको PrintAssembly विकल्प के गलत उपयोग के बारे में चेतावनी PrintAssembly । आइए इस कोड को चलाते हैं:

 java -client -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler -XX:CompileThreshold=5 -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly Test 

आउटपुट लंबा होगा, और इस तरह की लाइनें होंगी:

 0x00007f4b7cab1120: mov 0x8(%rsi),%r10d 0x00007f4b7cab1124: shl $0x3,%r10 0x00007f4b7cab1128: cmp %r10,%rax 

जैसा कि आप देख सकते हैं, संबंधित कार्यों को मूल मशीन कोड में संकलित किया गया है।

अंत में, विकल्प 3, एओटी पर चर्चा करें। निष्पादन से पहले संकलन, एओटी, संस्करण 9 से पहले जावा में उपलब्ध नहीं था।

JDK 9, jaotc में एक नया टूल सामने आया है - जैसा कि नाम से ही स्पष्ट है, यह जावा के लिए AOT कंपाइलर है। यह विचार है: जावा "जावा" कंपाइलर, फिर एओटी कंपाइलर जावा "जॉटक" के लिए और फिर जेवीएम "जावा" को हमेशा की तरह चलाएं। जेवीएम आम तौर पर व्याख्या और जेआईटी संकलन करता है। हालांकि, यदि फ़ंक्शन में एओटी-संकलित कोड है, तो यह सीधे इसका उपयोग करता है, और व्याख्या या जेआईटी संकलन का सहारा नहीं लेता है। मुझे समझाएं: आपको एओटी संकलक को चलाने की आवश्यकता नहीं है, यह वैकल्पिक है, और यदि आप इसका उपयोग करते हैं, तो आप केवल उन कक्षाओं को संकलित कर सकते हैं जिन्हें आप निष्पादित करने से पहले चाहते हैं।

आइए Test::f एओटी-संकलित संस्करण से मिलकर एक पुस्तकालय बनाएं। मत भूलो: अपने आप को ऐसा करने के लिए, आपको 150+ के निर्माण में JDK 9 की आवश्यकता होगी।

 jaotc --output=libTest.so Test.class 

नतीजतन, libTest.so उत्पन्न होता है, एक पुस्तकालय जिसमें Test क्लास में शामिल libTest.so -संकलित देशी कोड फ़ंक्शन शामिल हैं। आप इस लाइब्रेरी में परिभाषित वर्ण देख सकते हैं:

 nm libTest.so 

हमारे निष्कर्ष में, अन्य बातों के अलावा, निम्नलिखित होंगे:

 0000000000002120 t Test.f()I 00000000000021a0 t Test.<init>()V 00000000000020a0 t Test.main([Ljava/lang/String;)V 

इसलिए, हमारे सभी कार्य, कंस्ट्रक्टर, f , स्थिर विधि main पुस्तकालय libTest.so में मौजूद हैं।

जैसा कि संबंधित "जावा" विकल्प के मामले में, इस मामले में विकल्प एक फ़ाइल के साथ हो सकता है, इसके लिए jaotc के लिए -compile- कमांड विकल्प है। जेईपी 295 प्रासंगिक उदाहरण प्रदान करता है जो मैं यहां नहीं दिखाऊंगा।

चलो अब "जावा" चलाते हैं और देखते हैं कि क्या AOT- संकलित विधियों का उपयोग किया जाता है। यदि आप पहले की तरह "जावा" चलाते हैं, तो एओटी लाइब्रेरी का उपयोग नहीं किया जाएगा, और यह आश्चर्य की बात नहीं है। इस नई सुविधा का उपयोग करने के लिए, -XX:AOTLibrary विकल्प दिया गया है, जिसे आपको निर्दिष्ट करना होगा:

 java -XX:AOTLibrary=./libTest.so Test 

आप कई एओटी पुस्तकालयों को निर्दिष्ट कर सकते हैं, जिन्हें अल्पविराम द्वारा अलग किया जाता है।

इस कमांड का आउटपुट ठीक वैसा ही है, जब AOTLibrary बिना "जावा" शुरू AOTLibrary , क्योंकि टेस्ट प्रोग्राम का व्यवहार बिल्कुल भी नहीं बदला है। यह जांचने के लिए कि क्या AOT- संकलित कार्यों का उपयोग किया जाता है, आप एक और नया विकल्प जोड़ सकते हैं, -XX:+PrintAOT ।

 java -XX:AOTLibrary=./libTest.so -XX:+PrintAOT Test 

Test कार्यक्रम आउटपुट से पहले, यह आदेश निम्न दिखाता है:

  9 1 loaded ./libTest.so aot library 99 1 aot[ 1] Test.main([Ljava/lang/String;)V 99 2 aot[ 1] Test.f()I 99 3 aot[ 1] Test.<init>()V 

जैसा कि योजना बनाई गई है, एओटी पुस्तकालय भरी हुई है, और एओटी-संकलित कार्यों का उपयोग किया जाता है।

यदि आप रुचि रखते हैं, तो आप निम्न कमांड चला सकते हैं और जांच सकते हैं कि क्या JIT संकलन हो रहा है।

 java -client -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler -XX:CompileThreshold=5 -XX:-TieredCompilation -XX:AOTLibrary=./libTest.so -XX:+PrintAOT Test 

जैसा कि अपेक्षित था, जेआईटी संकलन नहीं होता है, क्योंकि निष्पादन से पहले टेस्ट क्लास में तरीकों को संकलित किया जाता है और लाइब्रेरी के रूप में प्रदान किया जाता है।

एक संभावित सवाल यह है: यदि हम एक मूल फ़ंक्शन कोड प्रदान करते हैं, तो जेवीएम कैसे निर्धारित करता है कि मूल कोड अप्रचलित / बासी है? अंतिम उदाहरण के रूप में, चलिए फ़ंक्शन को संशोधित करते हैं और ए को 6 पर सेट करते हैं।

 public int f() throws Exception { int a = 6; return a; } 

मैंने यह सिर्फ क्लास फाइल को संशोधित करने के लिए किया था। अब हम javac को संकलित करते हैं और ऊपर के समान कमांड चलाते हैं।

 javac Test.java java -client -Xbatch -XX:+PrintCompilation -XX:CompileCommandFile=hotspot_compiler -XX:CompileThreshold=5 -XX:-TieredCompilation -XX:AOTLibrary=./libTest.so -XX:+PrintAOT Test 

जैसा कि आप देख सकते हैं, मैंने "javac" के बाद "jaotc" नहीं चलाया, इसलिए AOT लाइब्रेरी का कोड अब पुराना और गलत है, और फ़ंक्शन f में a = 5 है।

ऊपर प्रदर्शित "जावा" कमांड का आउटपुट:

 228 56 b Test::<init> (5 bytes) 229 57 b Test::f (5 bytes) 

इसका मतलब है कि इस मामले में फ़ंक्शन गतिशील रूप से संकलित किए गए थे, इसलिए एओटी संकलन के परिणामस्वरूप कोड का उपयोग नहीं किया गया था। इसलिए, क्लास फाइल में बदलाव पाया गया है। जब javac का उपयोग करके संकलन किया जाता है, तो उसके फिंगरप्रिंट को कक्षा में प्रवेश किया जाता है, और क्लास फिंगरप्रिंट को AOT लाइब्रेरी में भी संग्रहीत किया जाता है। चूंकि वर्ग का नया फिंगरप्रिंट एओटी लाइब्रेरी में संग्रहीत से भिन्न होता है, इसलिए पहले से संकलित देशी कोड (एओटी) का उपयोग नहीं किया गया था। निष्पादन से पहले मैं आपको अंतिम संकलन विकल्प के बारे में बताना चाहता था।

इस लेख में, मैंने सरल यथार्थवादी उदाहरणों के साथ समझाने और समझाने की कोशिश की कि कैसे JVM जावा कोड को निष्पादित करता है: इसकी व्याख्या, गतिशील रूप से (JIT) या अग्रिम में (AOT) - इसके अलावा, अंतिम अवसर केवल JKK 9 में दिखाई दिया। मुझे आशा है कि आपने कुछ सीखा है नई।