जावाऑन: जावा मर्ज

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

हॉटस्पॉट और JRockit के विलय का कारण

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

आधार के रूप में जेवीएम को क्या लेना चाहिए?

प्रत्येक निर्णय की अपनी ताकत और कमजोरियां होती हैं। फिलहाल, हॉटस्पॉट की ताकत को व्यापक उपयोग, एक बड़ा ग्राहक आधार, उच्च दोष सहिष्णुता और प्रदर्शन माना जा सकता है। JRockit लिनक्स और विंडोज पर ओरेकल उत्पादों के ढेर के लिए अपने अनुकूलन के लिए बाहर खड़ा है, OS के बिना नंगे धातु पर चलने के लिए नरम वास्तविक समय के समाधान और संस्करणों की उपलब्धता (निश्चित रूप से, विशेष हार्डवेयर पर, और मनमाना नहीं)।

हैरानी की बात यह है कि आधार के रूप में जेवीएम को किस तरह लेना है, इसे लेकर लंबे समय से चर्चाएं थीं। परिणामस्वरूप, हॉटस्पॉट के पक्ष में निर्णय लिया गया, लेकिन तर्क तकनीकी नहीं थे। हॉटस्पॉट के आधार पर बनाए गए OpenJDK के कारण थे, हॉटस्पॉट पर काम करने वाले इंजीनियरों की संख्या (JRockit पर काम करने वाले इंजीनियर नए आम JDK में अपने वंश की विशेषताओं को लागू करेंगे), हॉटस्पॉट को संशोधित करने के लिए आईबीएम, एचपी और अन्य कंपनियों द्वारा जारी किए गए लाइसेंस। दुखद खबर यह भी है - सभी मर्ज OpenJDK में नहीं पड़ेंगे। विलय के पहले परिणाम जावा 7 में पहले ही देखे जा सकते हैं। उदाहरण के लिए, पहले से ही PermGen को C-heap में स्थानांतरित करने की योजना है। यह विलय के सभी काम दो साल के भीतर पूरा करने की योजना है।

एक आधुनिक आभासी मशीन के लिए आवश्यकताएँ

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

हॉटस्पॉट नवीनतम समाचार और अनुकूलन

NUMA आवंटन। आपको प्रोसेसर के करीब स्मृति में एक ऑब्जेक्ट बनाने की अनुमति देता है जिस पर काम होता है। चूंकि इस बात की संभावना है कि स्ट्रीम ने ऑब्जेक्ट बनाया है और इसके साथ अधिक काम करेगा, इसलिए लाभ चेहरे पर है। विभिन्न परीक्षणों में 25 से 300% की वृद्धि हुई है।

तार के साथ काम का अनुकूलन। यह एक रहस्य नहीं है कि विभिन्न एप्लिकेशन स्ट्रिंग्स के साथ बहुत काम करते हैं, और अगर प्रैम के साथ नहीं हैं, तो विभिन्न लाइब्रेरी तरीके उन्हें वैसे भी बनाते हैं। उदाहरण के लिए, स्ट्रिंग मर्जिंग (-XX: + OptimizeStringConcat), स्ट्रिंग की प्रतिलिपि बनाने, स्ट्रिंग संपीड़न (-XX: + UseCompressedStrings, केवल 6u21p में उपलब्ध, फिर अक्षम) जैसे अनुकूलन किए गए, जो आपको बाइट्स की एक सरणी में वर्णों को संग्रहीत करने की अनुमति देता है, यदि संभव हो, और। एक ही स्ट्रिंग कैशिंग (XX: + UseStringCache)।

संकुचित संकेत। यह स्वचालित रूप से चालू हो जाता है अगर जेवीएम तय करता है कि यह लाभ देगा। लेकिन आप इसे -XX: + UseCompressedOops पैरामीटर के साथ सक्षम कर सकते हैं। यह संपीड़न पाली के कारण होता है जो संरेखण के दौरान खोए हुए स्थान को कम करने में मदद करता है। इस विकल्प के साथ आप 32 जीबी तक मेमोरी के साथ काम कर सकते हैं। वे कहते हैं कि यह 32-बिट JVM से भी तेज काम करता है।

कचरा लड़ता है। संस्करण 6u14 से शुरू होकर, आप इसे -XX: + UseG1GC पैरामीटर के साथ सक्षम कर सकते हैं। यह कलेक्टर पहले से ही बहुत कठिन काम कर रहा है, लेकिन अभी तक समाप्त नहीं हुआ है, क्योंकि इसमें मामूली प्रदर्शन समस्याएं हैं (स्पाइक्स होते हैं)।

चरण संकलन। त्वरित स्टार्टअप के लिए, JVM क्लाइंट JIT कंपाइलर के साथ शुरू होता है, कुछ समय बाद कंपाइलर सर्वर एक में बदल जाता है।

ठीक है, ज़ाहिर है, पहले से ही कई बार पेशी एस्केपएनालिसिस और सरणियों की अधिक कुशल नकल।

JRockit लाभ

JRockit के सामने आप विश्वसनीयता और पूर्वानुमानशीलता को उजागर कर सकते हैं। एक सुसंगत धागा रुकावट मॉडल का उपयोग करना। शक्तिशाली जेआईटी संकलक। परीक्षण के लिए एपीआई अच्छी तरह से कवर करने वाले परीक्षणों का एक सेट है (जहाँ तक मुझे पता है हॉटस्पॉट की बहुत कमी है)। नमूना संकलक।

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

इसके जेवीएम में से कौन सा ओरेकल अब उपयोग करने की सलाह देता है?

यदि आप लिनक्स या विंडोज पर Oracle स्टैक के साथ काम कर रहे हैं, तो Oracle JRockit का उपयोग करने की सलाह देता है। अन्य सभी मामलों में - हॉटस्पॉट।

क्या कार्यक्षमता हस्तांतरित की जाएगी?

ओरेकल नए एकीकृत जेवीएम के लिए मिशन कंट्रोल को उपलब्ध कराना चाहता है। PermGen को देशी मेमोरी (सी-हीप) में बदलें। नकल के बिना I / O करें, जिसके लिए एक निश्चित प्रसंस्करण चरण में जीसी वस्तुओं के आंदोलन को प्रतिबंधित करने के लिए एक तंत्र को लागू करना आवश्यक होगा। कचरा संग्राहक और संकलक के प्रबंधन के लिए एक एपीआई बनाएं। खंडित स्मृति के साथ काम करने की क्षमता जोड़ें। नंगे धातु पर चलाना संभव बनाएं। और निश्चित रूप से, कचरे की कलेक्टर के सुधार में रुकावट की भविष्यवाणी के संदर्भ में।

एक संयुक्त JVM के विकास की संभावनाएँ

ओरेकल एकीकरण पर रोक लगाने का इरादा नहीं करता है, और कुछ परिप्रेक्ष्य में हम NUMA को चिंता के एक और विकास के रूप में NUMA चरम देखने की उम्मीद कर सकते हैं। इससे भी अधिक अनुमानित जी 1। वैकल्पिक रूप से बातचीत करने की वैकल्पिक क्षमता के साथ एक JVM में कई एप्लिकेशन चलाने की क्षमता। ऐतिहासिक डेटा और प्रारंभिक संकलन पर एर्गोनॉमिक्स। यह विचार पिछले लॉन्च के दौरान एकत्र किए गए डेटा और एप्लिकेशन को शुरू करने के दौरान उपयोग करने के लिए है। यह क्लस्टर / क्लाउड में जेवीएम के कुशल उपयोग की संभावना पर काम करने की भी योजना है, जब जेवीएम द्वारा आवंटित संसाधन बदल सकते हैं। विषम GPU प्रोसेसर का समर्थन करने की संभावना पर भी विचार किया जा रहा है।

निष्कर्ष में, स्पीकर ने एक मानक स्लाइड दिखाया जिसमें कहा गया था कि सब कुछ ओरेकल की वर्तमान योजनाएं हैं जो बदल सकती हैं, और उन्होंने कुछ भी वादा नहीं किया। उन्होंने जेवीएम विकास रणनीति के लिए जिम्मेदार एक ओरेकल कर्मचारी के ब्लॉग के लिंक की भी सिफारिश की।