दो सरल वर्गों के साथ शुरू करते हैं:
package com.michaelt.so.supers;
public class Sup {
int methodA(int a, int b) {
return a + b;
}
}
और फिर
package com.michaelt.so.supers;
public class Sub extends Sup {
@Override
int methodA(int a, int b) {
return super.methodA(a, b);
}
}
कम्पाइलिंग मेथड और बाइट कोड को देखते हुए एक हो जाता है:
methodA(II)I
L0
LINENUMBER 6 L0
ALOAD 0
ILOAD 1
ILOAD 2
INVOKESPECIAL com/michaelt/so/supers/Sup.methodA (II)I
IRETURN
L1
LOCALVARIABLE this Lcom/michaelt/so/supers/Sub; L0 L1 0
LOCALVARIABLE a I L0 L1 1
LOCALVARIABLE b I L0 L1 2
MAXSTACK = 3
MAXLOCALS = 3
और आप वहीं देख सकते हैं जो कि इनकॉस्पेक्टिव विधि के साथ यह सुपर क्लास मेथड () के खिलाफ लुकअप करता है।
Invokespecial opcode निम्नलिखित तर्क है:
- यदि C में एक ही नाम और वर्णनात्मक विधि के साथ एक उदाहरण विधि के लिए एक घोषणा शामिल है, तो यह विधि लागू होगी। लुकअप प्रक्रिया समाप्त हो जाती है।
- अन्यथा, यदि C का सुपरक्लास है, तो इसी लुकअप प्रक्रिया को सी के प्रत्यक्ष सुपरक्लास का उपयोग करके पुन: प्रदर्शित किया जाता है। जिस विधि को लागू किया जाना है वह इस लुकअप प्रक्रिया के पुनरावर्ती मंगलाचरण का परिणाम है।
- अन्यथा, एक AbstractMethodError उठाया जाता है।
इस मामले में, एक ही नाम और विवरणकर्ता के साथ कोई उदाहरण विधि नहीं है ताकि उसकी कक्षा में पहली गोली चल सके। हालांकि दूसरी गोली - एक सुपरक्लास होगी और यह सुपर के तरीके का आह्वान करती है।
कंपाइलर इनलाइन नहीं करता है और वर्ग में सुपर के स्रोत की कोई प्रतिलिपि नहीं है।
हालाँकि कहानी अभी खत्म नहीं हुई है। यह सिर्फ संकलित कोड है। कोड JVM हिट होने के बाद, हॉटस्पॉट शामिल हो सकता है।
दुर्भाग्य से, मैं इसके बारे में है कि ज्यादा पता नहीं है, इसलिए मैं इस मामले पर अधिकार के लिए अपील और के लिए जाना जाएगा जावा में इनलाइन किए जहां यह कहा जाता है कि हॉटस्पॉट कर सकते हैं तरीकों (यहां तक कि गैर अंतिम विधि) इनलाइन।
के लिए जा रहे डॉक्स को प्रभावी ढंग से Sup MethodA से कोड (कॉपी करने) उप MethodA में () - यह है कि एक विशेष विधि कॉल के बजाय कर रही है कि हर बार देखने, इस जानकारी को inlined किया जा सकता है की एक गर्म स्थान बन जाता है, तो विख्यात है।
यह रनटाइम पर किया जाता है, मेमोरी में, इस बात पर आधारित है कि एप्लिकेशन कैसे व्यवहार कर रहा है और प्रदर्शन को गति देने के लिए कौन से अनुकूलन आवश्यक हैं।
जैसा कि OpenJDK के लिए हॉटस्पॉट इंटर्नल्स में कहा गया है "विधियां अक्सर अंतर्निर्मित होती हैं। स्टेटिक, निजी, अंतिम और / या" विशेष "इनवोकेशन आसान इनलाइन हैं।"
यदि आप JVM के लिए विकल्पों में खुदाई करते हैं, तो आपको -XX:MaxInlineSize=35(35 डिफ़ॉल्ट होने का) एक विकल्प मिलेगा जो कि बाइट्स की अधिकतम संख्या है जो कि इनलाइन हो सकती है। मैं बताता हूं कि यही कारण है कि जावा को बहुत कम तरीके पसंद हैं - क्योंकि वे आसानी से इनलेट हो सकते हैं। वे छोटी विधियाँ तब तेज हो जाती हैं जब उन्हें अधिक कहा जाता है क्योंकि वे अंतर्निर्मित हो सकती हैं। और जबकि कोई उस नंबर के साथ खेल सकता है और इसे बड़ा बना सकता है, इससे अन्य अनुकूलन कम प्रभावी हो सकते हैं। (संबंधित एसओ सवाल: हॉटस्पॉट जेआईएल इनलाइनिंग रणनीति जो कि हॉटस्पॉट कर रहे इनलाइन के आंतरिक पर नज़र रखने के लिए कई अन्य विकल्पों को इंगित करती है)।
तो, नहीं - कोड संकलन समय पर इनबिल्ड नहीं है। और, हां - यदि प्रदर्शन अनुकूलन इसे जारी रखते हैं तो कोड रनटाइम पर बहुत अच्छी तरह से इनलेट हो सकता है।
और हॉटस्पॉट इनलाइन के बारे में मैंने जो कुछ भी लिखा है, वह केवल ओरेकल द्वारा वितरित हॉटस्पॉट जेवीएम पर लागू होता है। यदि आप जावा वर्चुअल मशीनों की विकिपीडिया की सूची को देखते हैं तो हॉटस्पॉट की तुलना में कई और अधिक हैं और जिस तरह से जेवीएम हैंडल को इनलाइनिंग करते हैं, वह ऊपर वर्णित की तुलना में पूरी तरह से अलग हो सकता है। अपाचे सद्भाव, Dalvik, एआरटी - चीजें वहां अलग तरह से काम कर सकती हैं।