आज बारहवें JVM LS शिखर सम्मेलन का समापन हुआ। हमेशा की तरह, यह आभासी मशीनों पर तकनीकी प्रस्तुतियों और उन पर चलने वाली भाषाओं के साथ एक कट्टर घटना थी। हमेशा की तरह, ओरेकल परिसर में सांता क्लारा में शिखर सम्मेलन आयोजित किया गया था। हमेशा की तरह, वहाँ बहुत से लोग चाहते हैं कि यहां जगह मिले: यहां प्रतिभागियों की संख्या 120 से अधिक नहीं है। हमेशा की तरह, कोई विपणन नहीं था, केवल अपमानजनक।

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

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

29 जुलाई

गदी शायबान - क्लोजर फ्यूचर्स

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

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

एलन बेटमैन और रिकार्ड बैक्मैन - प्रोजेक्ट लूम अपडेट

लूम परियोजना जावा के लिए एक हल्का फाइबर है। एक साल पहले, एलन और रॉन ने पहले ही इस परियोजना के बारे में बात की थी , और तब ऐसा लगा कि सब कुछ बहुत अच्छा चल रहा था और तैयार होने वाला था। हालाँकि, इस परियोजना ने अभी तक आधिकारिक रूप से जावा में प्रवेश नहीं किया है और अभी भी भंडार के एक अलग कांटे में विकसित किया जा रहा है। बेशक, यह पता चला कि बहुत सारे विवरणों का निपटान करना आवश्यक था।

ReentrantLock.lock से Socket.accept तक कई मानक API पहले से ही फ़ाइबर्स के लिए अनुकूलित किए जाते हैं: यदि इस तरह की कॉल फ़ाइबर के अंदर की जाती है, तो निष्पादन स्थिति बच जाएगी, स्टैक बेकार हो जाएगा और ऑपरेटिंग सिस्टम थ्रेड अन्य कार्यों के लिए तब तक मुक्त हो जाएगा जब तक कि कोई फ़ाइबर जागृत न हो जाए (उदाहरण के लिए, उदाहरण के लिए) ReentrantLock.unlock)। हालाँकि, उदाहरण के लिए, अच्छा पुराना सिंक्रोनाइज़्ड ब्लॉक अभी भी काम नहीं करता है और ऐसा लगता है, जेवीएम में सभी सिंक्रोनाइज़ेशन सपोर्ट को गंभीर रूप से रद्द किए बिना नहीं किया जा सकता है। यदि फाइबर की शुरुआत और ब्रेकपॉइंट के बीच स्टैक में देशी फ्रेम हैं, तो स्टैक का एक और अनइंडिंग काम नहीं करेगा। इन दोनों मामलों में, कुछ भी नहीं फटता है, लेकिन फाइबर धारा को जारी नहीं करता है।

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

यह उत्सुक है कि परियोजना के प्रतिभागियों ने अपने जीवन को आसान बनाने के लिए पहले से ही मुख्य JDK भंडार में कुछ प्रारंभिक बदलाव किए हैं। उदाहरण के लिए, जावा 13 में, प्रदर्शन विधि को जावा में पूरी तरह से मूल कोड से फिर से लिखा गया था, जिससे प्रदर्शन में लगभग 50 गुना वृद्धि हुई। यह एक लूम परियोजना क्यों है? तथ्य यह है कि यह विशेष विधि बहुत बार स्टैक के बीच में दिखाई देती है, और जब यह देशी था, तो इस स्टैक के फाइबर बंद नहीं हुए। एक तरह से या किसी अन्य, परियोजना पहले से ही लाभान्वित हो रही है।

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

ब्रायन गोएत्ज़ - कार्यशाला "प्रोजेक्ट एम्बर"

समानांतर में, लूम परियोजना के बारे में एक कार्यशाला चल रही थी, लेकिन मैं अंबर गया। यहां हमने परियोजना के उद्देश्यों और मुख्य JEP के बारे में संक्षेप में चर्चा की है जिसमें काम चल रहा है - पैटर्न मिलान , रिकॉर्ड्स और सील प्रकार । तब पूरी चर्चा डांट के निजी मुद्दे में आ गई। मैंने पिछले साल जोकर सम्मेलन में इस बारे में बात की थी , सिद्धांत रूप में, बहुत कुछ नया नहीं कहा गया था। मैंने एक विचार को निहित संघ प्रकारों के साथ धकेलने की कोशिश की जैसे if(obj instanceof Integer x || obj instanceof Long x) use(x.longValue()) , लेकिन मैंने उत्साह नहीं देखा।

जीन क्रिस्टोफ़ बेयलर, आर्थर यूबैंक्स और मैन काओ - जावा के लिए थ्रेड सैनिटाइज़िंग

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

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

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

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

ब्रायन गोएत्ज़ - वल्लाह अपडेट

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

तो, भाषा के दृष्टिकोण से, हमारे पास इनलाइन संशोधक वाली कक्षाएं हैं, जिन्हें वर्चुअल मशीन द्वारा एक विशेष तरीके से संसाधित किया जाता है। ऐसी कक्षाओं के उदाहरणों को अन्य वस्तुओं में एम्बेड किया जा सकता है, और इनलाइन कक्षाओं के उदाहरणों वाले फ्लैट सरणियों भी संभव हैं। उदाहरण में हेडर नहीं है, जिसका अर्थ है कि कोई पहचान नहीं है, हैश कोड की गणना फ़ील्ड द्वारा की जाती है, == फ़ील्ड द्वारा भी, ऐसे वर्ग पर सिंक्रनाइज़ या Object.wait() करने का प्रयास एक IllegalMonitorStestException बढ़ाएगा। इस प्रकार के एक चर के लिए null लेखन, निश्चित रूप से, काम नहीं करेगा। हालांकि, लेखक एक विकल्प प्रदान करते हैं: यदि आपने एक इनलाइन-क्लास Point घोषित किया है, तो आप एक फ़ील्ड या प्रकार के एक चर (आश्चर्य-आश्चर्य) की घोषणा कर सकते हैं Point? , और फिर एक हेडर, पहचान, और null साथ ढेर (जैसे मुक्केबाजी) पर एक पूर्ण ऑब्जेक्ट null वहाँ में फिट होगा।

गंभीर खुले प्रश्न जेनेरिक की विशेषज्ञता और मौजूदा वर्गों के प्रवासन (उदाहरण के लिए, Optional ) एक इनलाइन कक्षा में बने रहते हैं ताकि मौजूदा कोड को न तोड़े जा सके (हां, लोग Optional प्रकार के चर में null लिखते हैं)। फिर भी, चित्र घूमता है, और अंतर दिखाई देता है।

डेविड राइटन और नील गाफ्टर - सीएलआर में मूल्य प्रकार

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

व्लादिमीर इवानोव और जॉन रोज़ - वैक्टर और न्यूमेरिक्स जेवीएम पर

पिछले साल की रिपोर्ट को फिर से अपडेट करें। फिर, सवाल यह है कि उन्होंने अभी भी कुछ भी जारी नहीं किया है, अगर एक साल पहले सब कुछ बहुत अच्छा लग रहा था।

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

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

उपयोग भी अपूर्ण है। जावा में कोई ऑपरेटर अधिभार नहीं है, इसलिए गणित बदसूरत दिखता है: max(va-vb*42, 0) बजाय max(va-vb*42, 0) आपको va.lanewise(SUB, vb.lanewise(MUL, 42)).lanewise(MAX, 0) । C # की तरह AST lambdas तक पहुंचना अच्छा होगा। तब MYOP = binOp((va, vb) -> max(va-vb*42, 0)) जैसे कस्टम MYOP = binOp((va, vb) -> max(va-vb*42, 0)) ऑपरेशन उत्पन्न करना संभव होगा और इसका उपयोग करें।

30 जुलाई

दूसरा दिन संकलन के झंडे के नीचे से गुजरा।

मार्क स्टूडली - एओटी से लेकर जेआईटी और उससे आगे तक!

JVM OpenJ9 परियोजना का एक सदस्य आईबीएम कर्मचारी, JIT और AOT संकलन के साथ अपने अनुभव के बारे में बात करता है। हमेशा समस्याएं होती हैं: जेआईटी एक धीमा स्टार्टअप है, क्योंकि यह वार्मिंग है; संकलन के लिए सी.पी.यू. एओटी - एक प्रोफ़ाइल की कमी के कारण उप-गोद लेने का प्रदर्शन (यह प्रोफ़ाइल के लिए संभव है, लेकिन गैर-तुच्छ और हमेशा संकलन के दौरान प्रोफ़ाइल निष्पादन में मेल नहीं खाता है), इसका उपयोग करना अधिक कठिन है, लक्ष्य मंच, ओएस, कचरा कलेक्टर के लिए बाध्य करें। कुछ समस्याओं को दृष्टिकोणों को मिलाकर हल किया जा सकता है: AOT- संकलित कोड से शुरू करना और फिर JIT के साथ समाप्त करना। इस सब के लिए एक अच्छा विकल्प JIT कैशिंग है। यदि आपके पास बहुत सारी आभासी मशीनें (हैलो, माइक्रोसेर्विस) हैं, तो वे सभी एक अलग सेवा में बदल जाती हैं - जेआईटी कंपाइलर (हाँ, JITaaS), जहां सब कुछ एक वयस्क, ऑर्केस्ट्रेशन, लोड संतुलन की तरह होता है। यह सेवा संकलन करती है। अक्सर, वह एक निश्चित विधि के लिए तैयार कोड दे सकता है, क्योंकि यह विधि पहले से ही एक और जेवीएम पर संकलित की गई है। यह वार्म-अप में बहुत सुधार करता है, आपकी JVM सेवा से संसाधन खपत को हटाता है, और आम तौर पर कुल संसाधन खपत को कम करता है।

सामान्य तौर पर, JITaaS JVM की दुनिया में अगली चर्चा हो सकती है। दुर्भाग्य से, मैंने यह नहीं पकड़ा कि क्या इसे अभी खेला जा सकता है या क्या यह अभी भी एक बंद विकास है।

क्रिश्चियन विमर - ग्रेवलम नेटिव इमेज में सुधार

GraalVM नेटिव इमेज एक जावा एप्लिकेशन है जो मूल कोड में संकलित है जो JVM के बिना चलता है (AOT कंपाइलर जैसे jotot का उपयोग करके संकलित मॉड्यूल के विपरीत)। अधिक सटीक रूप से, यह काफी जावा अनुप्रयोग नहीं है। सही तरीके से काम करने के लिए, उसे एक बंद दुनिया की आवश्यकता है, अर्थात, सभी कोड संकलन चरण में दिखाई देने चाहिए, कोई Class.forName नहीं। आप प्रतिबिंब और विधि हैंडल कर सकते हैं, लेकिन जब आप संकलित करते हैं तो आपको विशेष रूप से यह बताना होगा कि प्रतिबिंब के माध्यम से कौन सी कक्षाएं और विधियों का उपयोग किया जाएगा।

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

वर्कशॉप शहतज़ल - हॉटस्पॉट जीसी।

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

मेई-चिन त्सई - सीएलआर में जेआईटी और एओटी

Microsoft मेई-चिन त्साई ने CLR में JIT और AOT संकलन की विशेषताओं के बारे में बात की। एओटी संकलन लंबे समय से उनके लिए विकसित हो रहा है, लेकिन शुरू में (ngen.exe) इसे टारगेट प्लेटफॉर्म पर किया गया था, पहली बार शुरू होने की तरह (अगर आपके पास विंडोज है, तो विंडोज फ़ोल्डर में * .ni.dll फाइलें देखें)। फ़ाइलें स्थानीय विंडोज के संस्करण और यहां तक ​​कि अन्य DLL-ek पर निर्भर होती हैं। तदनुसार, यदि निर्भरता को अद्यतन किया जाता है, तो सभी मूल मॉड्यूल को फिर से स्थापित किया जाना चाहिए। दूसरी पीढ़ी (क्रॉसगेन) में, लेखकों ने अनुप्रयोगों और मॉड्यूल को अपेक्षाकृत हार्डवेयर और ओएस संस्करणों और निर्भरताओं से स्वतंत्र रखा है। इसने कोड को धीमा कर दिया क्योंकि निर्भरता कॉल को अब ईमानदारी से आभासी बनाया जाना था। इस समस्या को JIT से जोड़कर और आवेदन के दौरान हॉट कोड को फिर से जोड़कर हल किया गया था। फिर हमने मल्टी-लेवल (tiered) संकलन के बारे में बात की (ऐसा लगता है कि CLR में यह अपनी प्रारंभिक अवस्था में है, जबकि यह जावा में कम से कम दस वर्षों से विकसित हो रहा है) और भविष्य में AOT को वास्तव में क्रॉस-प्लेटफॉर्म बनाने की योजना के बारे में।

वी कुई और ज़ियामिंग गु - जेवर्मप के साथ स्पीड जेवीएम प्रदर्शन

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

एक अलग समस्या है डीओप्टिमाइजेशन। पहले हजार प्रश्नों में, एक if हमेशा पहली शाखा के साथ-साथ चला जाता है, तो जेआईटी कंपाइलर आमतौर पर दूसरे को फेंक देता है, जिससे कोड आकार को कम करने के लिए एक डोप्टिमाइजेशन ट्रैप होता है। लेकिन 1001 वां अनुरोध दूसरी शाखा में चला गया, डेप्टिमाइजेशन ने काम किया और पूरी विधि दुभाषिए के पास गई। जबकि आँकड़े फिर से संकलित किए जा रहे हैं, जबकि विधि C1 संकलक द्वारा संकलित की जाती है, फिर C2 संकलक द्वारा पूर्ण प्रोफ़ाइल द्वारा, उपयोगकर्ताओं को एक मंदी का अनुभव होगा। और फिर एक ही विधि में एक और if deoptimized किया जा सकता है, और सब कुछ एक नया हो जाएगा।

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

यह ध्यान देने योग्य है कि त्वरित शुरुआत की समस्या यहां हल नहीं हुई है। एक प्रक्षेपण और भी धीमा हो सकता है क्योंकि कई विधियां संकलित की जाती हैं, जिनमें से कुछ को लॉन्च के कुछ मिनट बाद ही आवश्यक हो सकता है। लेकिन लॉग पुन: प्रयोज्य निकला: एओटी के विपरीत, आप सेवा को एक अलग आर्किटेक्चर पर या एक अलग कचरा संग्रहकर्ता के साथ उठा सकते हैं और पिछले लॉग का पुन: उपयोग कर सकते हैं।

लेखक JWarmUp को OpenJDK में धकेलने की लंबे समय से कोशिश कर रहे हैं । अब तक असफल, लेकिन काम चल रहा है। मुख्य बात यह है कि कोड रिव्यू सर्वर पर एक पूर्ण विकसित पैच अपने आप में काफी सुलभ है, इसलिए आप इसे आसानी से हॉटस्पॉट स्रोतों पर लागू कर सकते हैं और JWMUp के साथ स्वयं JVM का निर्माण कर सकते हैं।

जुआन फुमेरो - टोर्नाडो वीएम

यह मैनचेस्टर का एक शोध पत्र है, लेकिन लेखकों का दावा है कि परियोजना को कुछ स्थानों पर पहले ही लागू किया जा चुका है। यह OpenJDK के लिए एक ऐड-ऑन भी है, जो कि कुछ जावा कोड को GPU, iGPU, FPGA में स्थानांतरित करना आसान बनाता है या बस इसे अपने प्रोसेसर के कोर में समानांतर बनाता है। GPU पर संकलित करने के लिए, वे GraalVM का उपयोग करते हैं जिसमें उन्होंने अपना बैकएंड बनाया - TornadoJIT। एक सही ढंग से लिखा जावा विधि पारदर्शी रूप से संबंधित डिवाइस पर जाती है। सच है, वे कहते हैं कि FPGA पर संकलन में कई घंटे लग सकते हैं, लेकिन यदि आपका कार्य एक महीने का माना जाता है, तो क्यों नहीं। कुछ बेंचमार्क (उदाहरण के लिए, असतत फूरियर ट्रांसफॉर्म) नंगे जावा की तुलना में सौ गुना अधिक तेज हैं, जो सिद्धांत रूप में अपेक्षित है। परियोजना पूरी तरह से GitHub पर अपलोड की गई है , जहां आप विषय पर वैज्ञानिक प्रकाशन भी पा सकते हैं।

मौरिज़ियो सिमाडोमोर - पनामा का पुनर्निर्माण

सभी एक ही गीत - एक लंबे समय से चली आ रही परियोजना, हर शिखर प्रस्तुति, एक साल पहले सब कुछ बहुत तैयार लग रहा था, लेकिन अभी भी कोई रिलीज नहीं हुई थी। यह पता चला कि तब से ध्यान स्थानांतरित हो गया है।

परियोजना का विचार देशी कोड के साथ एक बेहतर अंतर है। हर कोई जानता है कि जेएनआई का उपयोग करना कितना दर्दनाक है। यह वास्तव में दर्द होता है। पनामा परियोजना इस दर्द को कम करती है: jextract जावा कक्षाओं का उपयोग देशी लाइब्रेरी की * .h फ़ाइलों से उत्पन्न होता है, जो कि देशी तरीकों को कॉल करके उपयोग करने के लिए काफी सुविधाजनक हैं। C / C ++ की तरफ, आपको एक भी लाइन नहीं लिखनी है। इसके अलावा, सब कुछ बहुत तेज हो गया: जावा पर कॉल ओवरहेड -> देशी और देशी-> जावा कई बार गिर गया। आपको और क्या चाहिए?

एक समस्या है जो लगभग कुछ समय से है - डेटा सरणियों को मूल कोड में स्थानांतरित करना। अब तक, अनुशंसित विधि DirectByteBuffer है, जिसमें बहुत सारी समस्याएं हैं। सबसे गंभीर में से एक अप्रबंधित जीवनकाल है (जब कचरा कलेक्टर उपयुक्त जावा ऑब्जेक्ट को उठाएगा तो बफर गायब हो जाएगा)। इस और अन्य समस्याओं के कारण, लोग Unsafe का उपयोग करते हैं, जो उचित परिश्रम के साथ, पूरी वर्चुअल मशीन को आसानी से लेट सकता है।

इसका मतलब है कि आपको जावा हीप के बाहर नए सामान्य मेमोरी एक्सेस की आवश्यकता है। आवंटन, संरचित पहुंच, स्पष्ट निष्कासन। संरचित एक्सेसर्स - ताकि आपको ऑफ़सेट्स की गणना स्वयं करने की आवश्यकता न हो यदि आपको लिखने की आवश्यकता है, उदाहरण के लिए, struct { byte x; int y; }[5] struct { byte x; int y; }[5] struct { byte x; int y; }[5] । इसके बजाय, आप एक बार इस संरचना के लेआउट का वर्णन करते हैं और फिर करते हैं, उदाहरण के लिए, VarHandle , जो y पर कूदकर सभी x पढ़ सकते हैं। इस मामले में, निश्चित रूप से, सामान्य जावा सरणियों में हमेशा सीमा की जाँच होनी चाहिए। इसके अलावा, पहले से ही बंद क्षेत्र तक पहुंच पर प्रतिबंध होना चाहिए। और यह एक गैर-तुच्छ कार्य हो जाता है अगर हम असुरक्षित स्तर पर प्रदर्शन बनाए रखना चाहते हैं और कई थ्रेड्स से पहुंच की अनुमति देते हैं। संक्षेप में, वीडियो देखें, बहुत दिलचस्प।

कार्यशाला: व्लादिमीर कोज़लोव - महानगर परियोजना

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

31 जुलाई

केविन Bourrillion - जावा के लिए अशक्तता एनोटेशन

केविन ने एक नई परियोजना की घोषणा की, लेकिन सार्वजनिक रूप से बात नहीं करने और YouTube पर अपने भाषण की रिकॉर्डिंग पोस्ट नहीं करने के लिए कहा। इसलिए क्षमा करें। , .

Dmitry Petrashko — Gradual typing for Ruby at Scale with Sorbet

Sorbet (!) Ruby, Ruby . , Stripe Ruby , , . , .

Lightning Talks

- . Remi Forax , , . , :

, - , .

Erik Meijer — Differentiable Programming

ML AI , . , Facebook — getafix , --, , . . , , . , , .

. . OpenJDK Committer Workshop.