जेवीएम हॉटस्पॉट में x86 के तहत बायोटेक इंटरप्रेटर का प्रारंभिककरण और संचालन

लगभग हर जावा डेवलपर जानता है कि जावा में लिखे गए कार्यक्रमों को शुरू में एक जेवीएम बाइटकोड में संकलित किया जाता है और एक मानक प्रारूप में वर्ग-फाइलों के रूप में संग्रहीत किया जाता है। वर्चुअल मशीन के अंदर ऐसी क्लास-फाइल्स मिलने के बाद और जब तक कंपाइलर उन तक नहीं पहुंच पाता, तब तक JVM इन क्लास-फाइल्स में मौजूद बायोटेक की व्याख्या करता है। यह आलेख बताता है कि OpenJDK JVM HotSpot के संबंध में दुभाषिया कैसे काम करता है।

लेख की सामग्री:

• पर्यावरण
• चल जावा आवेदन
• इंटरप्रिटर इनिशियलाइज़ेशन और कंट्रोल ट्रांसफर टू जावा कोड
• उदाहरण

पर्यावरण

प्रयोगों के लिए, हम autoconf कॉन्फ़िगरेशन के साथ नवीनतम उपलब्ध OpenJDK JDK12 संशोधन की असेंबली का उपयोग करते हैं

--enable-debug --with-native-debug-symbols=internal 

उबंटू 18.04 / gcc 7.4.0 पर।

--with-native-debug-symbols=internal अर्थ है कि, जेडडीके का निर्माण करते समय, बैराज प्रतीकों को स्वयं बायनेरिज़ में समाहित किया जाएगा।

--enable-debug - बाइनरी में अतिरिक्त डीबगिंग कोड होगा।

ऐसे माहौल में JDK 12 का निर्माण एक जटिल प्रक्रिया नहीं है। JDK11 को स्थापित करने के लिए ( JDK n, JDK n-1 की आवश्यकता है ) स्थापित करने के लिए मुझे जो कुछ भी करने की आवश्यकता थी वह सभी के लिए आवश्यक पुस्तकालयों ऑटोकैफ़ के लिए संकेत दिया गया था। इसके बाद, कमांड चलाएँ

 bash configure --enable-debug --with-native-debug-symbols=internal && make CONF=fastdebug images 

और थोड़ा इंतजार करने के बाद (मेरे लैपटॉप पर लगभग 10 मिनट), हमें JDK 12 का फास्टडबग बिल्ड मिलता है।

सिद्धांत रूप में, यह सार्वजनिक रिपॉजिटरी से बस jdk स्थापित करने के लिए काफी होगा और इसके अलावा डिबग प्रतीकों के साथ ओपनजेडक-एक्सएक्सएक्स-डीबीजी पैकेज वितरित करें, जहां xx jdk संस्करण है, लेकिन फास्टडबेक असेंबली gdb से डीबगिंग फ़ंक्शन प्रदान करता है जो कुछ मामलों में जीवन को आसान बना सकता है। फिलहाल, मैं सक्रिय रूप से ps () का उपयोग कर रहा हूं, gdb से जावा स्टैक के निशान देखने के लिए एक फ़ंक्शन, और pfl () , फ़्रेम के स्टैक का विश्लेषण करने के लिए एक फ़ंक्शन (यह gdb में दुभाषिया को डीबग करते समय बहुत सुविधाजनक है)।

 #   java file /home/dmitrii/jdk12/build/linux-x86_64-server-fastdebug/images/jdk/bin/java #   SEGV-, HotSpot #  SEGV  . #, https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/hotspot/cpu/x86/vm_version_x86.cpp#l361 handle SIGSEGV nostop noprint set breakpoint pending on set pagination off #  ,   #    # java- public static void main(String args[]) b PostJVMInit thread 2 commands #   , #    set $buf = (char *) malloc(1000) #        #(   ) b *AbstractInterpreter::_entry_table[0] thread 2 commands #      rbx. #   Method* set $mthd = ((Method *) $rbx) #    $buf call $mthd->name_and_sig_as_C_string($buf, 1000) # ,  public static void main(String args) if strcmp()("Main.main([Ljava/lang/String;)V", $buf) == 0 #   ,      # ps/pfl        #(    ps/pfl) b InterpreterRuntime::build_method_counters(JavaThread*, Method*) commands #  ,    #   delete breakpoints call ps() call pfl() c end end c end c end r -cp /home/dmitrii/jdk12/ Main 

 "Executing ps" for thread: "main" #1 prio=5 os_prio=0 cpu=468,61ms elapsed=58,65s tid=0x00007ffff001b800 nid=0x5bfa runnable [0x00007ffff7fd9000] java.lang.Thread.State: RUNNABLE Thread: 0x00007ffff001b800 [0x5bfa] State: _running _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_Java 1 - frame( sp=0x00007ffff7fd9920, unextended_sp=0x00007ffff7fd9920, fp=0x00007ffff7fd9968, pc=0x00007fffd828748b) Main.main(Main.java:10) "Executing pfl" for thread: "main" #1 prio=5 os_prio=0 cpu=468,83ms elapsed=58,71s tid=0x00007ffff001b800 nid=0x5bfa runnable [0x00007ffff7fd9000] java.lang.Thread.State: RUNNABLE Thread: 0x00007ffff001b800 [0x5bfa] State: _running _has_called_back 0 _at_poll_safepoint 0 JavaThread state: _thread_in_Java [Describe stack layout] 0x00007ffff7fd99e0: 0x00007ffff7fd9b00 #2 entry frame call_stub word fp - 0 0x00007ffff7fd99d8: 0x00007ffff7fd9c10 call_stub word fp - 1 0x00007ffff7fd99d0: 0x00007fffd8287160 call_stub word fp - 2 0x00007ffff7fd99c8: 0x00007fffbf1fb3e0 call_stub word fp - 3 0x00007ffff7fd99c0: 0x000000000000000a call_stub word fp - 4 0x00007ffff7fd99b8: 0x00007ffff7fd9ce8 call_stub word fp - 5 0x00007ffff7fd99b0: 0x00007ffff7fd9a80 call_stub word fp - 6 0x00007ffff7fd99a8: 0x00007ffff001b800 call_stub word fp - 7 0x00007ffff7fd99a0: 0x00007ffff7fd9b40 call_stub word fp - 8 0x00007ffff7fd9998: 0x00007ffff7fd9c00 call_stub word fp - 9 0x00007ffff7fd9990: 0x00007ffff7fd9a80 call_stub word fp - 10 0x00007ffff7fd9988: 0x00007ffff7fd9ce0 call_stub word fp - 11 0x00007ffff7fd9980: 0x00007fff00001fa0 call_stub word fp - 12 0x00007ffff7fd9978: 0x0000000716a122b8 sp for #2 locals for #1 unextended_sp for #2 local 0 0x00007ffff7fd9970: 0x00007fffd82719f3 0x00007ffff7fd9968: 0x00007ffff7fd99e0 #1 method Main.main([Ljava/lang/String;)V @ 0 - 1 locals 1 max stack 0x00007ffff7fd9960: 0x00007ffff7fd9978 interpreter_frame_sender_sp 0x00007ffff7fd9958: 0x0000000000000000 interpreter_frame_last_sp 0x00007ffff7fd9950: 0x00007fffbf1fb3e0 interpreter_frame_method 0x00007ffff7fd9948: 0x0000000716a11c40 interpreter_frame_mirror 0x00007ffff7fd9940: 0x0000000000000000 interpreter_frame_mdp 0x00007ffff7fd9938: 0x00007fffbf1fb5e8 interpreter_frame_cache 0x00007ffff7fd9930: 0x00007ffff7fd9978 interpreter_frame_locals 0x00007ffff7fd9928: 0x00007fffbf1fb3d0 interpreter_frame_bcp 0x00007ffff7fd9920: 0x00007ffff7fd9920 sp for #1 interpreter_frame_initial_sp unextended_sp for #1 

चल जावा आवेदन

सीधे दुभाषिया की चर्चा के लिए आगे बढ़ने से पहले, हम जावा कोड पर नियंत्रण स्थानांतरित करने से पहले की जाने वाली क्रियाओं की संक्षिप्त समीक्षा करेंगे। उदाहरण के लिए, एक जावा प्रोग्राम लें जो "कुछ भी नहीं करता है":

 public class Main { public static void main(String args[]){ } } 

और यह पता लगाने की कोशिश करें कि जब आप ऐसा एप्लिकेशन चलाते हैं तो क्या होता है:

javac Main.java && java Main

इस प्रश्न का उत्तर देने के लिए सबसे पहली बात यह है कि जावा बाइनरी को देखें और देखें - जिसे हम अपने सभी जेवीएम अनुप्रयोगों को चलाने के लिए उपयोग करते हैं। मेरे मामले में, यह पथ के साथ स्थित है

/home/dmitrii/jdk12/build/linux-x86_64-server-fastdebug/images/jdk/bin/java ।

लेकिन अंत में, देखने के लिए कुछ खास नहीं है। यह एक बाइनरी है, जो एक साथ debazhnymi प्रतीकों के साथ केवल 20KB लेता है और केवल एक स्रोत फ़ाइल लॉन्चर / main.c से संकलित किया जाता है।

वह जो करता है वह कमांड लाइन तर्क (चार * argv []) प्राप्त करता है, JDK_JAVA_OPTIONS पर्यावरण चर से तर्क पढ़ता है , बुनियादी प्रीप्रोसेसिंग और सत्यापन करता है (उदाहरण के लिए, आप इस पर्यावरण चर में एक टर्मिनल विकल्प या मुख्य वर्ग का नाम नहीं जोड़ सकते हैं) और फ़ंक्शन को कॉल करें। परिणामी तर्क सूची के साथ JLI_Launch ।

JLI_Launch फ़ंक्शन की परिभाषा जावा बाइनरी में निहित नहीं है और, यदि आप इसके प्रत्यक्ष निर्भरता को देखते हैं:

 $ ldd java linux-vdso.so.1 (0x00007ffcc97ec000) libjli.so => /home/dmitrii/jdk12/build/linux-x86_64-server-fastdebug/images/jdk/bin/./../lib/libjli.so (0x00007ff27518d000) // <---------    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff274d9c000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff274b7f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff27497b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff27475c000) /lib64/ld-linux-x86-64.so.2 (0x00007ff27559f000) 

आप libjli.so देख सकते हैं जो इससे जुड़ा हुआ है। इस लाइब्रेरी में लॉन्चर इंटरफ़ेस है - एक फ़ंक्शन का एक सेट जो जावा एक वर्चुअल मशीन को इनिशियलाइज़ और स्टार्ट करने के लिए उपयोग करता है, जिसके बीच में JLI_Launch है।

 $ objdump -T -j .text libjli.so libjli.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000009280 g DF .text 0000000000000038 Base JLI_List_add 0000000000003330 g DF .text 00000000000001c3 Base JLI_PreprocessArg 0000000000008180 g DF .text 0000000000000008 Base JLI_GetStdArgs 0000000000008190 g DF .text 0000000000000008 Base JLI_GetStdArgc 0000000000007e50 g DF .text 00000000000000b8 Base JLI_ReportErrorMessage 000000000000a400 g DF .text 00000000000000df Base JLI_ManifestIterate 0000000000002e70 g DF .text 0000000000000049 Base JLI_InitArgProcessing 0000000000008000 g DF .text 0000000000000011 Base JLI_ReportExceptionDescription 0000000000003500 g DF .text 0000000000000074 Base JLI_AddArgsFromEnvVar 0000000000007f10 g DF .text 00000000000000e9 Base JLI_ReportErrorMessageSys 0000000000005840 g DF .text 00000000000000b8 Base JLI_ReportMessage 0000000000009140 g DF .text 000000000000003a Base JLI_SetTraceLauncher 0000000000009020 g DF .text 000000000000000a Base JLI_MemFree 0000000000008f90 g DF .text 0000000000000026 Base JLI_MemAlloc 00000000000059c0 g DF .text 0000000000002013 Base JLI_Launch 00000000000091c0 g DF .text 000000000000003b Base JLI_List_new 0000000000008ff0 g DF .text 0000000000000026 Base JLI_StringDup 0000000000002ec0 g DF .text 000000000000000c Base JLI_GetAppArgIndex 

JLI_Launch पर नियंत्रण के हस्तांतरण के बाद, JVM को शुरू करने के लिए कई कार्यों की आवश्यकता होती है, जैसे:

मैं एक वीएम बनाने के लिए JVM HotSpot वर्णों को मेमोरी में लोड करना और फ़ंक्शन के लिए एक पॉइंटर प्राप्त करना।

सभी JVM HotSpot कोड libjvm.so लाइब्रेरी में स्थित है। Libjvm.so के लिए पूर्ण पथ का निर्धारण करने के बाद, लाइब्रेरी को मेमोरी में लोड किया जाता है और जेएनआई_क्रीट जेवावीएमएम पॉइंटर को इंगित किया जाता है । यह फ़ंक्शन पॉइंटर संग्रहीत किया जाता है और बाद में वर्चुअल मशीन को बनाने और आरंभ करने के लिए उपयोग किया जाता है।

जाहिर है libjvm.so libjli.so से जुड़ी नहीं है

II । प्रीप्रोसेसिंग के बाद पार्सिंग तर्क पारित हुए।

ParseArguments बोलने वाले नाम के साथ एक फ़ंक्शन कमांड लाइन से पारित तर्कों को पार्स करता है। यह तर्क पार्सर एप्लिकेशन स्टार्टअप मोड को परिभाषित करता है

 enum LaunchMode { // cf. sun.launcher.LauncherHelper LM_UNKNOWN = 0, LM_CLASS, LM_JAR, LM_MODULE, LM_SOURCE }; 

यह तर्कों के भाग को प्रारूप -DpropertyName=propertyValue भी रूपांतरित करता है, उदाहरण के लिए -Djava.class.path=/path को -Djava.class.path=/path रूपांतरित किया -Djava.class.path=/path । इसके अलावा, इस तरह की SystemProperty को JVM हॉटस्पॉट में वैश्विक सरणी में संग्रहीत किया जाता है और java.lang.System::props भेज दिया जाता है java.lang.System::props आरंभीकरण के पहले चरण में java.lang.System::props (JDK12 में, java .lang.System.props के आरंभीकरण तंत्र को संशोधित किया गया है, इस कमिट में और अधिक)।

पार्सिंग तर्कों में कुछ विकल्प भी शामिल हैं जो जेवीएम द्वारा संसाधित नहीं किए जाते हैं (उदाहरण के लिए --list-modules , इस विकल्प का प्रसंस्करण सीधे इस बिंदु पर लांचर में होता है)।

III । एक प्राइमरी थ्रेड फोर्क करें और इसमें एक वीएम बनाएं

लेकिन अगर कुछ गलत हो गया है, तो मुख्य धागे में जेवीएम शुरू करने का प्रयास किया जाता है "बस इसे आज़माएं"।

प्रश्न का अध्ययन करने के बाद, मैंने संभावित कारणों में से एक पाया कि जेवीएम मुख्य धागे में क्यों नहीं शुरू होता है। तथ्य यह है कि (कम से कम लिनक्स पर) pthreads और मुख्य धागा स्टैक के साथ अलग-अलग काम करते हैं। मुख्य-सूत्र का आकार ulimit -s द्वारा सीमित है, अर्थात। मनमाने ढंग से बड़े मूल्य निर्धारित करते समय, हम एक मनमाने ढंग से बड़े स्टैक प्राप्त करते हैं। मुख्य धागा MAP_GROWSDOWN के समान कुछ का उपयोग करता है, लेकिन MAP_GROWSDOWN नहीं। अपने शुद्ध रूप में MAP_GROWSDOWN का उपयोग करना सुरक्षित नहीं है और, यदि स्मृति मुझे सही सेवा देती है, तो लॉक है। मेरी मशीन पर, MAP_GROWSDOWN कोई प्रभाव नहीं डालता है। मुख्य-थ्रेड मैपिंग और MAP_GROWSDOWN के बीच का अंतर यह है कि MAP_FIXED के अपवाद के साथ कोई अन्य mmap संभव स्टैक विस्तार के क्षेत्र के साथ एक संघर्ष करने में सक्षम नहीं होगा। सॉफ्टवेयर से सभी की जरूरत है कि संबंधित rsp मूल्य निर्धारित किया rsp और फिर ओएस इसका पता rsp : और पेज-फॉल्ट प्रक्रिया करेगा और गार्ड सेट करेगा । यह अंतर कई रेक को प्रभावित करता है: गार्ड स्ट्रीम बनाते समय , वर्तमान स्ट्रीम के स्टैक का आकार निर्धारित करते समय

इसलिए, हम मान लेंगे कि फिलहाल हमने विकल्पों को सफलतापूर्वक पार कर लिया है और VM के लिए एक धागा बनाया है। उसके बाद, बस कांटा हुआ धागा एक आभासी मशीन बनाना शुरू करता है और थ्रेड्स :: create_vm फ़ंक्शन में प्रवेश करता है

इस फ़ंक्शन में, एक बड़ी संख्या बनाई जाती है काला जादू आरंभीकरण, हम उनमें से केवल कुछ में रुचि रखेंगे।

इंटरप्रेटर की शुरूआत और जावा कोड पर नियंत्रण का हस्तांतरण

जेवीएम हॉटस्पॉट में प्रत्येक निर्देश के लिए एक विशिष्ट वास्तुकला के लिए एक विशिष्ट मशीन कोड टेम्पलेट है। जब दुभाषिया एक निर्देश को निष्पादित करना शुरू करता है, तो पहली चीज जो उसके लिए दिखती है वह है विशेष डिस्पैच टेबल में इसके टेम्पलेट का पता। अगला, इस टेम्प्लेट के पते पर जाएं और निर्देश के निष्पादन के पूरा होने के बाद, jvm क्रम में अगले निर्देश का पता निकालता है) और इसे उसी तरह निष्पादित करना शुरू करता है, और इसी तरह। इस व्यवहार को केवल "प्रेषण" न करने वाले निर्देशों के लिए दुभाषिया के साथ देखा जाता है, उदाहरण के लिए, अंकगणितीय निर्देश ( xsub , xsub , आदि, जहां x - i , l , f , d )। वे सभी अंकगणितीय ऑपरेशन करते हैं।

प्रक्रियाओं के मामले में मंगलाचरण निर्देश ( invokestatic , invokevirtual , इत्यादि), निष्पादित होने वाला अगला निर्देश पहली प्रक्रिया होगी जिसे तथाकथित प्रक्रिया कहा जाएगा। ऐसे निर्देश स्वयं अपने टेम्पलेट में निष्पादित किए जाने वाले अगले बायोटेकोड-निर्देश का पता डालते हैं।

Threads::create_vm में इस मशीन के संचालन को सुनिश्चित करने के लिए Threads::create_vm , कई इनिशियलाइज़ेशन किए जाते हैं जिन पर दुभाषिया निर्भर करता है:

मैं उपलब्ध बाइटकोड की तालिका को आरम्भ करना

दुभाषिया के आरंभ के साथ आगे बढ़ने से पहले, उपयोग किए गए बायोटेक की तालिका को आरंभीकृत करना आवश्यक है। इसे बाइटकोड्स में निष्पादित किया जाता है :: फ़ंक्शन को इनिशियलाइज़ करें और इसे बहुत पठनीय लेबल के रूप में प्रस्तुत किया जाए। इसका टुकड़ा निम्नानुसार है:

  // Java bytecodes // bytecode bytecode name format wide f. result tp stk traps def(_nop , "nop" , "b" , NULL , T_VOID , 0, false); def(_aconst_null , "aconst_null" , "b" , NULL , T_OBJECT , 1, false); def(_iconst_m1 , "iconst_m1" , "b" , NULL , T_INT , 1, false); def(_iconst_0 , "iconst_0" , "b" , NULL , T_INT , 1, false); def(_iconst_1 , "iconst_1" , "b" , NULL , T_INT , 1, false); def(_iconst_2 , "iconst_2" , "b" , NULL , T_INT , 1, false); def(_iconst_3 , "iconst_3" , "b" , NULL , T_INT , 1, false); def(_iconst_4 , "iconst_4" , "b" , NULL , T_INT , 1, false); def(_iconst_5 , "iconst_5" , "b" , NULL , T_INT , 1, false); def(_lconst_0 , "lconst_0" , "b" , NULL , T_LONG , 2, false); def(_lconst_1 , "lconst_1" , "b" , NULL , T_LONG , 2, false); def(_fconst_0 , "fconst_0" , "b" , NULL , T_FLOAT , 1, false); def(_fconst_1 , "fconst_1" , "b" , NULL , T_FLOAT , 1, false); def(_fconst_2 , "fconst_2" , "b" , NULL , T_FLOAT , 1, false); def(_dconst_0 , "dconst_0" , "b" , NULL , T_DOUBLE , 2, false); def(_dconst_1 , "dconst_1" , "b" , NULL , T_DOUBLE , 2, false); def(_bipush , "bipush" , "bc" , NULL , T_INT , 1, false); def(_sipush , "sipush" , "bcc" , NULL , T_INT , 1, false); def(_ldc , "ldc" , "bk" , NULL , T_ILLEGAL, 1, true ); def(_ldc_w , "ldc_w" , "bkk" , NULL , T_ILLEGAL, 1, true ); def(_ldc2_w , "ldc2_w" , "bkk" , NULL , T_ILLEGAL, 2, true ); 

इस तालिका के अनुसार, प्रत्येक बाइटकोड के लिए इसकी लंबाई निर्धारित की जाती है (आकार हमेशा 1 बाइट होता है, लेकिन ConstantPool में एक इंडेक्स भी हो सकता है, साथ ही साथ विस्तृत बायोटेक भी हो सकता है), नाम, बाइटकोड और झंडे:

 bool Bytecodes::_is_initialized = false; const char* Bytecodes::_name [Bytecodes::number_of_codes]; BasicType Bytecodes::_result_type [Bytecodes::number_of_codes]; s_char Bytecodes::_depth [Bytecodes::number_of_codes]; u_char Bytecodes::_lengths [Bytecodes::number_of_codes]; Bytecodes::Code Bytecodes::_java_code [Bytecodes::number_of_codes]; unsigned short Bytecodes::_flags [(1<<BitsPerByte)*2]; 

दुभाषिया टेम्पलेट कोड उत्पन्न करने के लिए इन मापदंडों की आवश्यकता है।

II । प्रारंभिक कैश कोड

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

  CodeCacheExpansionSize = align_up(CodeCacheExpansionSize, os::vm_page_size()); if (SegmentedCodeCache) { // Use multiple code heaps initialize_heaps(); } else { // Use a single code heap FLAG_SET_ERGO(uintx, NonNMethodCodeHeapSize, 0); FLAG_SET_ERGO(uintx, ProfiledCodeHeapSize, 0); FLAG_SET_ERGO(uintx, NonProfiledCodeHeapSize, 0); ReservedCodeSpace rs = reserve_heap_memory(ReservedCodeCacheSize); add_heap(rs, "CodeCache", CodeBlobType::All); } 

कैश कोड विकल्प -XX:ReservedCodeCacheSize द्वारा नियंत्रित किया -XX:ReservedCodeCacheSize , -XX:SegmentedCodeCache , -XX:CodeCacheExpansionSize , -XX:NonNMethodCodeHeapSize , -XX:ProfiledCodeHeapSize , -XX:NonProfiledCodeHeapSize । इन विकल्पों का एक संक्षिप्त विवरण उन लिंक्स पर पाया जा सकता है जिनके लिए वे नेतृत्व करते हैं। कमांड लाइन के अलावा, इनमें से कुछ विकल्पों के मूल्यों को एर्गोनोमिक रूप से समायोजित किया जाता है, उदाहरण के लिए, यदि SegmentedCodeCache मान का SegmentedCodeCache डिफ़ॉल्ट रूप से (बंद) SegmentedCodeCache है, तो कोड आकार के साथ >= 240Mb , SegmentedCodeCache को CompilerConfig :: set_tiered_flags में शामिल किया जाएगा।

जाँच करने के बाद, आकार का एक क्षेत्र ReservedCodeCacheSize बाइट्स ReservedCodeCacheSize । यदि SegmentedCodeCache उजागर हो गया, तो यह क्षेत्र भागों में विभाजित है: JIT- संकलित विधियाँ, छुरा रूटीन, आदि।

III । दुभाषिया पैटर्न की शुरुआत

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

व्यक्तिगत रूप से इनमें से प्रत्येक चरण पर विचार करें:

• slow_signature_handler

  { CodeletMark cm(_masm, "slow signature handler"); AbstractInterpreter::_slow_signature_handler = generate_slow_signature_handler(); } 

हस्ताक्षर हैंडलर का उपयोग देशी तरीकों पर कॉल के लिए तर्क तैयार करने के लिए किया जाता है। इस मामले में, एक सामान्य हैंडलर उत्पन्न होता है, उदाहरण के लिए, मूल विधि में 13 से अधिक तर्क हैं (मैंने डिबगर में इसकी जांच नहीं की थी, लेकिन कोड को देखते हुए यह इस तरह होना चाहिए)

• अवैध बायोटेक प्रसंस्करण

  { CodeletMark cm(_masm, "error exits"); _unimplemented_bytecode = generate_error_exit("unimplemented bytecode"); _illegal_bytecode_sequence = generate_error_exit("illegal bytecode sequence - method not verified"); } 

VM आरंभीकरण के दौरान क्लासफाइल्स को मान्य करता है, लेकिन ऐसा तब होता है जब स्टैक पर दिए गए तर्क उस प्रारूप में नहीं होते हैं जिसकी जरूरत होती है या बाईटकोड जिसके बारे में वीएम को पता नहीं होता है। ये स्टब्स तब उपयोग किए जाते हैं जब प्रत्येक बायोटेक के लिए टेम्प्लेट कोड बनाते हैं।

• फ़ंक्शन से वापस लौटें

प्रक्रियाओं को कॉल करने के बाद, फ्रेम स्टैक से डेटा को पुनर्स्थापित करना आवश्यक है, जो कि उस प्रक्रिया के लिए कॉल से पहले था जिसमें से रिटर्न किया जाता है।

• earlyret

दुभाषिया से रनटाइम कॉल करते समय उपयोग किया जाता है।

• अपवाद फेंकना

  
  

• विधि प्रवेश बिंदु

  
  

   #define method_entry(kind) \ { CodeletMark cm(_masm, "method entry point (kind = " #kind ")"); \ Interpreter::_entry_table[Interpreter::kind] = generate_method_entry(Interpreter::kind); \ Interpreter::update_cds_entry_table(Interpreter::kind); \ } 

  
  

  विधि के प्रकार के आधार पर मैक्रो के रूप में प्रस्तुत किया गया। सामान्य मामले में, व्याख्या किए गए स्टैक फ्रेम की तैयारी की जाती है, स्टैकऑवरफ्लो चेक, स्टैक-बैंगिंग। देशी तरीकों के लिए, एक हस्ताक्षर हैंडलर परिभाषित किया गया है।

  
  

• बायटेकोड टेम्पलेट जनरेशन

  
  

  // Bytecodes set_entry_points_for_all_bytes(); // installation of code in other places in the runtime // (ExcutableCodeManager calls not needed to copy the entries) set_safepoints_for_all_bytes(); 

निर्देश को निष्पादित करने के लिए, वीएम विनिर्देश को ऑपरेंड स्टैक में होने की आवश्यकता होती है, लेकिन यह हॉटस्पॉट को रजिस्टर में कैशिंग करने से नहीं रोकता है। स्टैक के शीर्ष की वर्तमान स्थिति को निर्धारित करने के लिए, एक गणना का उपयोग किया जाता है ।

 enum TosState { // describes the tos cache contents btos = 0, // byte, bool tos cached ztos = 1, // byte, bool tos cached ctos = 2, // char tos cached stos = 3, // short tos cached itos = 4, // int tos cached ltos = 5, // long tos cached ftos = 6, // float tos cached dtos = 7, // double tos cached atos = 8, // object cached vtos = 9, // tos not cached number_of_states, ilgl // illegal state: should not occur }; 

प्रत्येक निर्देश ढेर के ऊपर TosState के इनपुट और आउटपुट स्थिति को परिभाषित करता है, और पैटर्न की पीढ़ी इस स्थिति के आधार पर होती है। ये टेम्पलेट एक पठनीय टेम्पलेट तालिका में आरंभीकृत होते हैं। इस तालिका का एक अंश इस प्रकार है:

 // interpr. templates // Java spec bytecodes ubcp|disp|clvm|iswd in out generator argument def(Bytecodes::_nop , ____|____|____|____, vtos, vtos, nop , _ ); def(Bytecodes::_aconst_null , ____|____|____|____, vtos, atos, aconst_null , _ ); def(Bytecodes::_iconst_m1 , ____|____|____|____, vtos, itos, iconst , -1 ); def(Bytecodes::_iconst_0 , ____|____|____|____, vtos, itos, iconst , 0 ); def(Bytecodes::_iconst_1 , ____|____|____|____, vtos, itos, iconst , 1 ); def(Bytecodes::_iconst_2 , ____|____|____|____, vtos, itos, iconst , 2 ); def(Bytecodes::_iconst_3 , ____|____|____|____, vtos, itos, iconst , 3 ); def(Bytecodes::_iconst_4 , ____|____|____|____, vtos, itos, iconst , 4 ); def(Bytecodes::_iconst_5 , ____|____|____|____, vtos, itos, iconst , 5 ); def(Bytecodes::_lconst_0 , ____|____|____|____, vtos, ltos, lconst , 0 ); def(Bytecodes::_lconst_1 , ____|____|____|____, vtos, ltos, lconst , 1 ); def(Bytecodes::_fconst_0 , ____|____|____|____, vtos, ftos, fconst , 0 ); def(Bytecodes::_fconst_1 , ____|____|____|____, vtos, ftos, fconst , 1 ); def(Bytecodes::_fconst_2 , ____|____|____|____, vtos, ftos, fconst , 2 ); def(Bytecodes::_dconst_0 , ____|____|____|____, vtos, dtos, dconst , 0 ); def(Bytecodes::_dconst_1 , ____|____|____|____, vtos, dtos, dconst , 1 ); def(Bytecodes::_bipush , ubcp|____|____|____, vtos, itos, bipush , _ ); def(Bytecodes::_sipush , ubcp|____|____|____, vtos, itos, sipush , _ ); 

हम विशेष रूप in , out और generator कॉलम in रुचि लेंगे।

in - निर्देश शुरू होने के समय स्टैक के शीर्ष की स्थिति
निर्देश के पूरा होने के समय स्टैक के शीर्ष की स्थिति
generator - मशीन अनुदेश कोड टेम्पलेट के जनरेटर

सभी बाइटकोड के लिए टेम्पलेट का सामान्य दृश्य इस प्रकार वर्णित किया जा सकता है:

1. यदि निर्देश के लिए प्रेषण बिट सेट नहीं है, तो अनुदेश प्रस्ताव निष्पादित किया जाता है (x86 पर नो-ऑप)

   
   

2. generator का उपयोग करके, मशीन कोड उत्पन्न होता है

   
   

3. यदि निर्देश के लिए प्रेषण बिट सेट नहीं है, तो अगली अनुदेश के लिए संक्रमण स्टैक के शीर्ष की बाहरी स्थिति के आधार पर किया out , जो अगले निर्देश के लिए होगा

   
   

परिणामी टेम्पलेट के लिए प्रवेश बिंदु पता वैश्विक तालिका में संग्रहीत किया जाता है और डीबगिंग के लिए उपयोग किया जा सकता है।

हॉटस्पॉट में, इसके लिए अपेक्षाकृत निम्न डंबल कोड जिम्मेदार है:

 void TemplateInterpreterGenerator::set_entry_points(Bytecodes::Code code) { CodeletMark cm(_masm, Bytecodes::name(code), code); // initialize entry points assert(_unimplemented_bytecode != NULL, "should have been generated before"); assert(_illegal_bytecode_sequence != NULL, "should have been generated before"); address bep = _illegal_bytecode_sequence; address zep = _illegal_bytecode_sequence; address cep = _illegal_bytecode_sequence; address sep = _illegal_bytecode_sequence; address aep = _illegal_bytecode_sequence; address iep = _illegal_bytecode_sequence; address lep = _illegal_bytecode_sequence; address fep = _illegal_bytecode_sequence; address dep = _illegal_bytecode_sequence; address vep = _unimplemented_bytecode; address wep = _unimplemented_bytecode; // code for short & wide version of bytecode if (Bytecodes::is_defined(code)) { Template* t = TemplateTable::template_for(code); assert(t->is_valid(), "just checking"); set_short_entry_points(t, bep, cep, sep, aep, iep, lep, fep, dep, vep); } if (Bytecodes::wide_is_defined(code)) { Template* t = TemplateTable::template_for_wide(code); assert(t->is_valid(), "just checking"); set_wide_entry_point(t, wep); } // set entry points EntryPoint entry(bep, zep, cep, sep, aep, iep, lep, fep, dep, vep); Interpreter::_normal_table.set_entry(code, entry); Interpreter::_wentry_point[code] = wep; } //... void TemplateInterpreterGenerator::set_short_entry_points(Template* t, address& bep, address& cep, address& sep, address& aep, address& iep, address& lep, address& fep, address& dep, address& vep) { assert(t->is_valid(), "template must exist"); switch (t->tos_in()) { case btos: case ztos: case ctos: case stos: ShouldNotReachHere(); // btos/ctos/stos should use itos. break; case atos: vep = __ pc(); __ pop(atos); aep = __ pc(); generate_and_dispatch(t); break; case itos: vep = __ pc(); __ pop(itos); iep = __ pc(); generate_and_dispatch(t); break; case ltos: vep = __ pc(); __ pop(ltos); lep = __ pc(); generate_and_dispatch(t); break; case ftos: vep = __ pc(); __ pop(ftos); fep = __ pc(); generate_and_dispatch(t); break; case dtos: vep = __ pc(); __ pop(dtos); dep = __ pc(); generate_and_dispatch(t); break; case vtos: set_vtos_entry_points(t, bep, cep, sep, aep, iep, lep, fep, dep, vep); break; default : ShouldNotReachHere(); break; } } //... void TemplateInterpreterGenerator::generate_and_dispatch(Template* t, TosState tos_out) { if (PrintBytecodeHistogram) histogram_bytecode(t); #ifndef PRODUCT // debugging code if (CountBytecodes || TraceBytecodes || StopInterpreterAt > 0) count_bytecode(); if (PrintBytecodePairHistogram) histogram_bytecode_pair(t); if (TraceBytecodes) trace_bytecode(t); if (StopInterpreterAt > 0) stop_interpreter_at(); __ verify_FPU(1, t->tos_in()); #endif // !PRODUCT int step = 0; if (!t->does_dispatch()) { step = t->is_wide() ? Bytecodes::wide_length_for(t->bytecode()) : Bytecodes::length_for(t->bytecode()); if (tos_out == ilgl) tos_out = t->tos_out(); // compute bytecode size assert(step > 0, "just checkin'"); // setup stuff for dispatching next bytecode if (ProfileInterpreter && VerifyDataPointer && MethodData::bytecode_has_profile(t->bytecode())) { __ verify_method_data_pointer(); } __ dispatch_prolog(tos_out, step); } // generate template t->generate(_masm); // advance if (t->does_dispatch()) { #ifdef ASSERT // make sure execution doesn't go beyond this point if code is broken __ should_not_reach_here(); #endif // ASSERT } else { // dispatch to next bytecode __ dispatch_epilog(tos_out, step); } } 

, . JVM. Java- . JavaCalls . JVM , main .

, , :

 public class Sum{ public static void sum(int a, int b){ return a + b; } } public class Main { public static void main(String args[]){ Sum.sum(2, 3); } } 

Sum.sum(II) .

2 javac -c *.java , .
Sum.sum :

  descriptor: (II)I flags: (0x0009) ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=2, args_size=2 0: iload_0 1: iload_1 2: iadd 3: ireturn LineNumberTable: line 3: 0 

Main.main

  descriptor: ([Ljava/lang/String;)V flags: (0x0009) ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=1, args_size=1 0: iconst_2 1: iconst_3 2: invokestatic #2 // Method Sum.sum:(II)I 5: pop 6: return LineNumberTable: line 13: 0 line 14: 6 

, — .

invokestatic ' x86 - HotSpot

 void TemplateTable::invokestatic(int byte_no) { transition(vtos, vtos); assert(byte_no == f1_byte, "use this argument"); prepare_invoke(byte_no, rbx); // get f1 Method* // do the call __ profile_call(rax); __ profile_arguments_type(rax, rbx, rbcp, false); __ jump_from_interpreted(rbx, rax); } 

byte_no == f1_byte — ConstantPoolCache , , rbx — , Method * . : , , ( method_entry ).

prepare_invoke . , invokestatic ConstantPool Constant_Methodref_Info . HotSpot . 2 .. ConstantPoolCache . ConstantPoolCache , (, ConstantPoolCacheEntry , ). ConstantPoolCacheEntry , ( 0) / . , ConstantPool , ConstantPoolCache ( x86 Little Endian).

, , HotSpot prepare_invoke — ConstantPoolCache . , , ConstantPoolCacheEntry

  __ get_cache_and_index_and_bytecode_at_bcp(Rcache, index, temp, byte_no, 1, index_size); __ cmpl(temp, code); // have we resolved this bytecode? __ jcc(Assembler::equal, resolved); // resolve first time through address entry = CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_from_cache); __ movl(temp, code); __ call_VM(noreg, entry, temp); // Update registers with resolved info __ get_cache_and_index_at_bcp(Rcache, index, 1, index_size); __ bind(resolved); 

, InterpreterRuntime::resolve_from_cache .

receiver'a , . (, , , ConstantPoolCache <clinit> , ). define class, EagerInitialization ( , , :)). HotSpot ( CDS ) .

, , ConstantPoolCacheEntry . Method * rbx , , .

Sum.sum(2, 3) . gdb-script sum.gdb :

 #    java file /home/dmitrii/jdk12/build/linux-x86_64-server-fastdebug/images/jdk/bin/java # gdb    SEGV' #,   https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/hotspot/cpu/x86/vm_version_x86.cpp#l361 handle SIGSEGV nostop noprint #       set breakpoint pending on #    , #    set pagination off #      main b PostJVMInit commands #   , #    set $buffer = malloc(1000) #   . #jmp       # invokestatic b *AbstractInterpreter::_entry_table[0] thread 2 commands #     invokestatic, # Method*   rbx set $mthd = (Method *) $rbx #    $buffer call $mthd->name_and_sig_as_C_string($buffer, 1000) if strcmp()($buffer, "Sum.sum(II)I") == 0 #  iload_0,     b *TemplateInterpreter::_normal_table._table[vtos][26] thread 2 #  iload_1,   - int,  #  iload_0 b *TemplateInterpreter::_normal_table._table[itos][27] thread 2 #   iadd b *TemplateInterpreter::_normal_table._table[itos][96] thread 2 end c end c end r -cp . Main 

gdb -x sum.gdb , Sum.sum

 $453 = 0x7ffff7fdcdd0 "Sum.sum(II)I" 

layout asm , , generate_normal_entry . -, StackOverflow, stack-banging dispatch iload_0 . :

 0x7fffd828fa1f mov eax,DWORD PTR [r14] ;, iload_0 0x7fffd828fa22 movzx ebx,BYTE PTR [r13+0x1] ;   0x7fffd828fa27 inc r13 ; bcp (byte code pointer) 0x7fffd828fa2a movabs r10,0x7ffff717e8a0 ; DispatchTable 0x7fffd828fa34 jmp QWORD PTR [r10+rbx*8] ;jump      

rax ,

 0x7fffd828fabe push rax ;     ;   ,      0x7fffd828fabf mov eax,DWORD PTR [r14-0x8] 0x7fffd828fac3 movzx ebx,BYTE PTR [r13+0x1] 0x7fffd828fac8 inc r13 0x7fffd828facb movabs r10,0x7ffff717e8a0 0x7fffd828fad5 jmp QWORD PTR [r10+rbx*8] 

iadd :

 0x7fffd8292ba7 mov edx,DWORD PTR [rsp] ; ,     iload_1 0x7fffd8292baa add rsp,0x8 ; rsp    0x7fffd8292bae add eax,edx ;   0x7fffd8292bb0 movzx ebx,BYTE PTR [r13+0x1] 0x7fffd8292bb5 inc r13 0x7fffd8292bb8 movabs r10,0x7ffff717e8a0 0x7fffd8292bc2 jmp QWORD PTR [r10+rbx*8] 

gdb eax edx ,

 (gdb) p $eax $457 = 3 (gdb) p $edx $458 = 2 

, Sum.sum .