समय-समय पर संकलन

From alpha
Jump to navigation Jump to search

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

JIT संकलन मशीन कोड-अहेड-ऑफ-टाइम संकलन (AOT) और इंटरप्रेटर (कंप्यूटिंग) में अनुवाद के लिए दो पारंपरिक दृष्टिकोणों का एक संयोजन है - और दोनों के कुछ फायदे और कमियां जोड़ता है।[2] मोटे तौर पर, JIT संकलन संकलित कोड की गति को व्याख्या के लचीलेपन के साथ जोड़ता है, एक दुभाषिया के ओवरहेड और संकलन और लिंकर (कंप्यूटिंग) के अतिरिक्त ओवरहेड के साथ (केवल व्याख्या नहीं)। JIT संकलन गतिशील संकलन का एक रूप है, और अनुकूली अनुकूलन की अनुमति देता है जैसे कि गतिशील पुनर्संकलन और microआर्किटेक्चर-विशिष्ट स्पीडअप।[nb 1][3]व्याख्या और JIT संकलन गतिशील प्रोग्रामिंग भाषाओं के लिए विशेष रूप से अनुकूल हैं, क्योंकि रनटाइम सिस्टम देर से बांधना | लेट-बाउंड डेटा प्रकारों को संभाल सकता है और सुरक्षा गारंटी लागू कर सकता है।

इतिहास

1960 में जॉन मैक्कार्थी (कंप्यूटर वैज्ञानिक) द्वारा सबसे पहले प्रकाशित जेआईटी कंपाइलर को आमतौर पर लिस्प (प्रोग्रामिंग भाषा) पर काम करने के लिए जिम्मेदार ठहराया जाता है।[4] अपने सेमिनल पेपर में सांकेतिक अभिव्यक्तियों के पुनरावर्ती कार्य और मशीन द्वारा उनकी गणना, भाग I, वह उन कार्यों का उल्लेख करता है जो रनटाइम के दौरान अनुवादित होते हैं, जिससे छिद्र पत्रकों के लिए संकलक आउटपुट को बचाने की आवश्यकता होती है।[5](हालांकि यह अधिक सटीक रूप से कंपाइल एंड गो सिस्टम के रूप में जाना जाएगा)। एक और प्रारंभिक उदाहरण केन थॉम्पसन द्वारा दिया गया था, जिन्होंने 1968 QED (पाठ संपादक) QED (टेक्स्ट एडिटर) में पैटर्न मिलान के लिए नियमित अभिव्यक्ति के पहले अनुप्रयोगों में से एक दिया था।[6] गति के लिए, थॉम्पसन ने संगत समय-साझाकरण प्रणाली पर JITing द्वारा IBM 7094 कोड से नियमित अभिव्यक्ति मिलान लागू किया।[4] 1970 में जेम्स जी. मिशेल द्वारा व्याख्या से संकलित कोड प्राप्त करने के लिए एक प्रभावशाली तकनीक का नेतृत्व किया गया था, जिसे उन्होंने प्रायोगिक भाषा LC² के लिए लागू किया था।[7][8]

स्मॉलटॉक (c. 1983) ने JIT संकलनों के नए पहलुओं का मार्ग प्रशस्त किया। उदाहरण के लिए, मशीन कोड में अनुवाद मांग पर किया गया था, और परिणाम बाद में उपयोग के लिए कैश किया गया था। जब स्मृति दुर्लभ हो जाती है, तो सिस्टम इस कोड में से कुछ को हटा देता है और जब इसकी आवश्यकता होती है तो इसे पुन: उत्पन्न करता है।[2][9]Sun's Self (प्रोग्रामिंग लैंग्वेज) लैंग्वेज ने इन तकनीकों में बड़े पैमाने पर सुधार किया और एक समय में यह दुनिया की सबसे तेज़ स्मॉलटाक प्रणाली थी, जो अनुकूलित C की आधी गति तक पहुँचती थी।[10]लेकिन पूरी तरह से वस्तु-उन्मुख भाषा के साथ।

स्वयं को सूर्य ने छोड़ दिया था, लेकिन शोध जावा भाषा में चला गया। जस्ट-इन-टाइम संकलन शब्द को मैन्युफैक्चरिंग टर्म बस समय में (व्यवसाय) से उधार लिया गया था और जावा द्वारा लोकप्रिय किया गया था, जेम्स गोस्लिंग ने 1993 से इस शब्द का उपयोग किया था।[11] वर्तमान में JITing का उपयोग जावा वर्चुअल मशीन के अधिकांश कार्यान्वयनों द्वारा किया जाता है, जैसा कि हॉटस्पॉट (वर्चुअल मशीन) बनाता है, और इस शोध आधार का बड़े पैमाने पर उपयोग करता है।

एचपी परियोजना डायनमो एक प्रायोगिक जेआईटी संकलक था जहां 'बाइटकोड' प्रारूप और मशीन कोड प्रारूप समान थे; सिस्टम ने PA-6000 मशीन कोड को PA-8000 मशीन कोड में बदल दिया।[12]सहज रूप से, इसके परिणामस्वरूप 30% के कुछ मामलों में मशीन कोड स्तर पर अनुकूलन की अनुमति दी गई, उदाहरण के लिए, बेहतर कैश उपयोग के लिए इनलाइनिंग कोड और गतिशील पुस्तकालयों के लिए कॉल के अनुकूलन और कई अन्य रन-टाइम अनुकूलन जो पारंपरिक हैं संकलक प्रयास करने में सक्षम नहीं हैं।[13][14]

नवंबर 2020 में, PHP 8.0 ने JIT कंपाइलर पेश किया।[15]


डिजाइन

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

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

JIT कोड आमतौर पर दुभाषियों की तुलना में कहीं बेहतर प्रदर्शन प्रदान करता है। इसके अलावा, यह कुछ मामलों में स्थिर संकलन की तुलना में बेहतर प्रदर्शन प्रदान कर सकता है, क्योंकि कई अनुकूलन केवल रन-टाइम पर ही संभव हैं:[16][17]

  1. संकलन को लक्षित सीपीयू और ऑपरेटिंग सिस्टम मॉडल के लिए अनुकूलित किया जा सकता है जहां एप्लिकेशन चलता है। उदाहरण के लिए, JIT SSE2 वेक्टर CPU निर्देश चुन सकता है जब यह पता लगाता है कि CPU उनका समर्थन करता है। एक स्थिर संकलक के साथ अनुकूलन विशिष्टता के इस स्तर को प्राप्त करने के लिए, किसी को या तो प्रत्येक इच्छित प्लेटफॉर्म/आर्किटेक्चर के लिए एक बाइनरी संकलित करना होगा, या फिर एक बाइनरी के भीतर कोड के कुछ हिस्सों के कई संस्करणों को शामिल करना होगा।
  2. सिस्टम इस बारे में आँकड़े एकत्र करने में सक्षम है कि प्रोग्राम वास्तव में उस वातावरण में कैसे चल रहा है, और यह इष्टतम प्रदर्शन के लिए पुनर्व्यवस्थित और पुन: संकलित कर सकता है। हालाँकि, कुछ स्टैटिक कंपाइलर प्रोफ़ाइल जानकारी को इनपुट के रूप में भी ले सकते हैं।
  3. सिस्टम डायनेमिक लिंकिंग के फायदों को खोए बिना और स्टैटिक कंपाइलर्स और लिंकर्स में निहित ओवरहेड्स के बिना ग्लोबल कोड ऑप्टिमाइज़ेशन (जैसे लाइब्रेरी फ़ंक्शंस का इनलाइन विस्तार) कर सकता है। विशेष रूप से, वैश्विक इनलाइन प्रतिस्थापन करते समय, एक स्थिर संकलन प्रक्रिया को रन-टाइम चेक की आवश्यकता हो सकती है और सुनिश्चित करें कि वर्चुअल कॉल तब होगी जब ऑब्जेक्ट की वास्तविक कक्षा इनलाइन विधि को ओवरराइड करती है, और सरणी एक्सेस पर सीमा स्थिति जांच को संसाधित करने की आवश्यकता हो सकती है। छोरों के भीतर। कई मामलों में समय-समय पर संकलन के साथ इस प्रसंस्करण को लूप से बाहर ले जाया जा सकता है, अक्सर गति में बड़ी वृद्धि होती है।
  4. हालांकि यह वैधानिक रूप से संकलित कचरा एकत्रित भाषाओं के साथ संभव है, बेहतर कैश उपयोग के लिए एक बायटेकोड सिस्टम अधिक आसानी से निष्पादित कोड को पुनर्व्यवस्थित कर सकता है।

क्योंकि एक JIT को रनटाइम पर एक मूल बाइनरी इमेज को रेंडर और निष्पादित करना चाहिए, ट्रू मशीन-कोड JITs को प्लेटफॉर्म की आवश्यकता होती है जो डेटा को रनटाइम पर निष्पादित करने की अनुमति देता है, ऐसे JIT का उपयोग हार्वर्ड वास्तुकला-आधारित मशीन पर असंभव बना देता है; कुछ ऑपरेटिंग सिस्टम और वर्चुअल मशीनों के लिए भी यही कहा जा सकता है। हालाँकि, एक विशेष प्रकार का JIT संभावित रूप से भौतिक मशीन के CPU आर्किटेक्चर को लक्षित नहीं कर सकता है, बल्कि एक अनुकूलित VM बायटेकोड है जहाँ कच्चे मशीन कोड की सीमाएँ प्रबल होती हैं, विशेषकर जहाँ उस बायटेकोड का VM अंततः एक JIT को मूल कोड में ले जाता है।[18]


प्रदर्शन

बायोटेक को लोड करने और संकलित करने में लगने वाले समय के कारण, जेआईटी किसी एप्लिकेशन के प्रारंभिक निष्पादन में थोड़ी देर से ध्यान देने योग्य देरी का कारण बनता है। कभी-कभी इस विलंब को स्टार्टअप समय विलंब या वार्म-अप समय कहा जाता है। सामान्य तौर पर, JIT जितना अधिक अनुकूलन करता है, उतना ही बेहतर कोड उत्पन्न होगा, लेकिन प्रारंभिक विलंब भी बढ़ेगा। एक जेआईटी कंपाइलर को इसलिए संकलन समय और उस कोड की गुणवत्ता के बीच समझौता करना पड़ता है जो इसे उत्पन्न करने की उम्मीद करता है। स्टार्टअप समय में JIT संकलन के अलावा बढ़े हुए IO-बाउंड ऑपरेशन शामिल हो सकते हैं: उदाहरण के लिए, जावा वर्चुअल मशीन (JVM) के लिए rt.jar क्लास डेटा फ़ाइल 40 एमबी है और JVM को इस प्रासंगिक विशाल फ़ाइल में बहुत अधिक डेटा की तलाश करनी चाहिए .[19]

सन के हॉटस्पॉट (वर्चुअल मशीन) जावा वर्चुअल मशीन द्वारा उपयोग किया जाने वाला एक संभावित अनुकूलन व्याख्या और जेआईटी संकलन को संयोजित करना है। एप्लिकेशन कोड की शुरुआत में व्याख्या की जाती है, लेकिन JVM मॉनिटर करता है कि बायटेकोड के कौन से क्रम अक्सर निष्पादित होते हैं और हार्डवेयर पर सीधे निष्पादन के लिए उन्हें मशीन कोड में अनुवादित करते हैं। बायटेकोड के लिए जिसे केवल कुछ ही बार निष्पादित किया जाता है, यह संकलन समय बचाता है और प्रारंभिक विलंबता को कम करता है; अक्सर निष्पादित बायटेकोड के लिए, धीमी व्याख्या के प्रारंभिक चरण के बाद, जेआईटी संकलन का उपयोग उच्च गति पर चलाने के लिए किया जाता है। इसके अतिरिक्त, चूंकि एक कार्यक्रम अपने कोड के अल्पांश को क्रियान्वित करने में सबसे अधिक समय व्यतीत करता है, कम संकलन समय महत्वपूर्ण है। अंत में, प्रारंभिक कोड व्याख्या के दौरान, संकलन से पहले निष्पादन आँकड़े एकत्र किए जा सकते हैं, जो बेहतर अनुकूलन करने में मदद करता है।[20]

परिस्थितियों के कारण सही ट्रेडऑफ़ भिन्न हो सकता है। उदाहरण के लिए, सन की जावा वर्चुअल मशीन के दो प्रमुख मोड हैं- क्लाइंट और सर्वर। क्लाइंट मोड में स्टार्टअप समय को कम करने के लिए न्यूनतम संकलन और अनुकूलन किया जाता है। सर्वर मोड में, व्यापक संकलन और अनुकूलन किया जाता है, स्टार्टअप समय का त्याग करके एप्लिकेशन के चलने के बाद प्रदर्शन को अधिकतम करने के लिए। अन्य जावा जस्ट-इन-टाइम कंपाइलर्स ने एक विधि के बाइटकोड आकार के साथ संयुक्त रूप से निष्पादन की संख्या के रनटाइम माप का उपयोग किया है, यह तय करने के लिए कि कब संकलन करना है।[21] फिर भी एक अन्य लूप का पता लगाने के साथ संयुक्त रूप से निष्पादित की गई संख्या का उपयोग करता है।[22]सामान्य तौर पर, लंबे समय तक चलने वाले अनुप्रयोगों की तुलना में शॉर्ट-रनिंग एप्लिकेशन में कौन से तरीकों का अनुकूलन करना है, इसका सटीक अनुमान लगाना बहुत कठिन है।[23]

Microsoft द्वारा देशी छवि जनरेटर (Ngen) प्रारंभिक विलंब को कम करने का एक और तरीका है।[24]Ngen प्री-कंपाइल (या प्री-JITs) बायटेकोड को एक सामान्य मध्यवर्ती भाषा इमेज में मशीन नेटिव कोड में बदल देता है। नतीजतन, कोई रनटाइम संकलन की आवश्यकता नहीं है। Visual Studio 2005 के साथ शिप किया गया .NET Framework 2.0 स्थापना के ठीक बाद सभी Microsoft लाइब्रेरी DLL पर Ngen चलाता है। प्री-जिंगिंग स्टार्टअप समय को बेहतर बनाने का एक तरीका प्रदान करता है। हालाँकि, यह उत्पन्न होने वाले कोड की गुणवत्ता उतनी अच्छी नहीं हो सकती है जितनी कि JITed है, उन्हीं कारणों से कोड को स्थिर रूप से संकलित किया गया है, प्रोफ़ाइल-निर्देशित अनुकूलन के बिना, चरम मामले में JIT संकलित कोड जितना अच्छा नहीं हो सकता है: कमी ड्राइव करने के लिए प्रोफाइलिंग डेटा, उदाहरण के लिए, इनलाइन कैशिंग।[25]

ऐसे जावा कार्यान्वयन भी मौजूद हैं जो समय से पहले संकलन|एओटी (समय से पहले) संकलक को या तो जेआईटी संकलक (एक्सेलसियर जेट) या दुभाषिया (जावा के लिए जीएनयू संकलक) के साथ जोड़ते हैं।

JIT संकलन अपने लक्ष्य को मज़बूती से प्राप्त नहीं कर सकता है, अर्थात् एक छोटी प्रारंभिक वार्मअप अवधि के बाद बेहतर प्रदर्शन की स्थिर स्थिति में प्रवेश करना।[26][27] आठ विभिन्न वर्चुअल मशीनों में, Barrett et al. (2017) छह व्यापक रूप से उपयोग किए जाने वाले microbenchmark को मापा गया जो आमतौर पर वर्चुअल मशीन कार्यान्वयनकर्ताओं द्वारा अनुकूलन लक्ष्य के रूप में उपयोग किया जाता है, उन्हें एक ही प्रक्रिया निष्पादन के भीतर बार-बार चलाया जाता है।[28] लिनक्स पर, उन्होंने पाया कि 8.7% से 9.6% प्रक्रिया निष्पादन प्रदर्शन की स्थिर स्थिति तक पहुंचने में विफल रही, 16.7% से 17.9% ने वार्मअप अवधि के बाद कम प्रदर्शन की स्थिर स्थिति में प्रवेश किया, और एक विशिष्ट वर्चुअल मशीन के 56.5% जोड़े चल रहे थे एक विशिष्ट बेंचमार्क लगातार कई निष्पादनों में प्रदर्शन की स्थिर-अवस्था गैर-निम्नीकरण देखने में विफल रहा (यानी, कम से कम एक निष्पादन स्थिर स्थिति तक पहुंचने में विफल रहा या स्थिर स्थिति में प्रदर्शन में कमी देखी गई)। यहां तक ​​​​कि जहां एक बेहतर स्थिर-स्थिति तक पहुंच गया था, वहां कभी-कभी सैकड़ों पुनरावृत्तियां हुईं।[29] Traini et al. (2022) इसके बजाय हॉटस्पॉट वर्चुअल मशीन पर ध्यान केंद्रित किया गया लेकिन बेंचमार्क की एक विस्तृत श्रृंखला के साथ,[30] यह पाया गया कि 10.9% प्रक्रिया निष्पादन प्रदर्शन की स्थिर स्थिति तक पहुँचने में विफल रहे, और 43.5% बेंचमार्क लगातार कई निष्पादनों में स्थिर स्थिति प्राप्त नहीं कर पाए।[31]


सुरक्षा

JIT संकलन मूल रूप से निष्पादन योग्य डेटा का उपयोग करता है, और इस प्रकार सुरक्षा चुनौतियों और संभावित कारनामों को प्रस्तुत करता है।

JIT संकलन के कार्यान्वयन में स्रोत कोड या बाइट कोड को मशीन कोड में संकलित करना और उसे निष्पादित करना शामिल है। यह आम तौर पर सीधे मेमोरी में किया जाता है: JIT कंपाइलर मशीन कोड को सीधे मेमोरी में आउटपुट करता है और इसे डिस्क पर आउटपुट करने के बजाय तुरंत निष्पादित करता है और फिर कोड को एक अलग प्रोग्राम के रूप में आमंत्रित करता है, जैसा कि समय संकलन से पहले होता है। निष्पादन योग्य स्थान सुरक्षा के कारण आधुनिक आर्किटेक्चर में यह एक समस्या में चला जाता है: मनमाने ढंग से स्मृति को निष्पादित नहीं किया जा सकता है, अन्यथा एक संभावित सुरक्षा छेद है। इस प्रकार मेमोरी को निष्पादन योग्य के रूप में चिह्नित किया जाना चाहिए; सुरक्षा कारणों से यह कोड को स्मृति में लिखे जाने के बाद किया जाना चाहिए, और केवल पढ़ने के लिए चिह्नित किया जाना चाहिए, क्योंकि लिखने योग्य/निष्पादन योग्य स्मृति एक सुरक्षा छेद है (W^X देखें)।[32]उदाहरण के लिए, जावास्क्रिप्ट के लिए फ़ायरफ़ॉक्स के जेआईटी कंपाइलर ने फ़ायरफ़ॉक्स 46 के रिलीज़ संस्करण में इस सुरक्षा को पेश किया।[33]

JIT छिड़काव कंप्यूटर सुरक्षा कारनामों का एक वर्ग है जो हीप छिड़काव के लिए JIT संकलन का उपयोग करता है: परिणामी मेमोरी तब निष्पादन योग्य होती है, जो एक शोषण की अनुमति देती है यदि निष्पादन को हीप में ले जाया जा सकता है।

उपयोग

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

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

यह भी देखें

टिप्पणियाँ

  1. Ahead-of-Time compilers can target specific microarchitectures as well, but the difference between AOT and JIT in that matter is one of portability. A JIT can render code tailored to the currently running CPU at runtime, whereas an AOT, in lieu of optimizing for a generalized subset of uarches, must know the target CPU in advance: such code may not only be not performant on other CPU types but may be outright unstable.


संदर्भ

  1. Languages, Compilers, and Runtime Systems, University of Michigan, Computer Science and Engineering, retrieved March 15, 2018
  2. 2.0 2.1 2.2 Aycock 2003.
  3. "Does the JIT take advantage of my CPU?". David Notario's WebLog. Retrieved 2018-12-03.
  4. 4.0 4.1 Aycock 2003, 2. JIT Compilation Techniques, 2.1 Genesis, p. 98.
  5. McCarthy, J. (April 1960). "Recursive functions of symbolic expressions and their computation by machine, Part I". Communications of the ACM. 3 (4): 184–195. CiteSeerX 10.1.1.111.8833. doi:10.1145/367177.367199. S2CID 1489409.
  6. Thompson 1968.
  7. Aycock 2003, 2. JIT Compilation Techniques, 2.2 LC², p. 98–99.
  8. Mitchell, J.G. (1970). "The design and construction of flexible and efficient interactive programming systems". {{cite journal}}: Cite journal requires |journal= (help)
  9. Deutsch, L.P.; Schiffman, A.M. (1984). "Efficient implementation of the Smalltalk-80 system" (PDF). POPL '84: Proceedings of the 11th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages: 297–302. doi:10.1145/800017.800542. ISBN 0-89791-125-3. S2CID 3045432. Archived from the original (PDF) on 2004-06-18.
  10. "Archived copy". research.sun.com. Archived from the original on 24 November 2006. Retrieved 15 January 2022.{{cite web}}: CS1 maint: archived copy as title (link)
  11. Aycock 2003, 2.14 Java, p. 107, footnote 13.
  12. "Dynamo: A Transparent Dynamic Optimization System". Vasanth Bala, Evelyn Duesterwald, Sanjeev Banerjia. PLDI '00 Proceedings of the ACM SIGPLAN 2000 conference on Programming language design and implementation. pages 1 to 12. DOI 10.1145/349299.349303. Retrieved March 28, 2012
  13. John Jannotti. "HP's Dynamo". Ars Technica. Retrieved 2013-07-05.
  14. "The HP Dynamo Project". Archived from the original on October 19, 2002. Retrieved 2016-04-12.{{cite web}}: CS1 maint: unfit URL (link)
  15. Tung, Liam (27 November 2020). "Programming language PHP 8 is out: This new JIT compiler points to better performance". ZDNet. Retrieved 28 November 2020.
  16. Croce, Louis. "Just in Time Compilation" (PDF). Columbia University. Archived from the original (PDF) on 2018-05-03.
  17. "What are the advantages of JIT vs. AOT compilation". Stack Overflow. Jan 21, 2010.
  18. "Compile a JIT based lang to Webassembly". Stack Overflow. Retrieved 2018-12-04.
  19. Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved 2007-07-27.
  20. "The Java HotSpot Performance Engine Architecture". Oracle.com. Retrieved 2013-07-05.
  21. Schilling, Jonathan L. (February 2003). "The simplest heuristics may be the best in Java JIT compilers" (PDF). SIGPLAN Notices. 38 (2): 36–46. doi:10.1145/772970.772975. S2CID 15117148. Archived from the original (PDF) on 2015-09-24.
  22. Toshio Suganuma, Toshiaki Yasue, Motohiro Kawahito, Hideaki Komatsu, Toshio Nakatani, "A dynamic optimization framework for a Java just-in-time compiler", Proceedings of the 16th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications (OOPSLA '01), pp. 180–195, October 14–18, 2001.
  23. Matthew Arnold, Michael Hind, Barbara G. Ryder, "An Empirical Study of Selective Optimization", Proceedings of the 13th International Workshop on Languages and Compilers for Parallel Computing-Revised Papers, pp. 49–67, August 10–12, 2000.
  24. "Native Image Generator (Ngen.exe)". Msdn2.microsoft.com. Retrieved 2013-07-05.
  25. Sweeney, Arnold (February 2005). "A Survey of Adaptive Optimization in Virtual Machines" (PDF). Proceedings of the IEEE. 92 (2): 449–466. Archived from the original (PDF) on 2016-06-29.
  26. Barrett et al. 2017, p. 3.
  27. Traini et al. 2022, p. 1.
  28. Barrett et al. 2017, p. 5-6.
  29. Barrett et al. 2017, p. 12-13.
  30. Traini et al. 2022, p. 17-23.
  31. Traini et al. 2022, p. 26-29.
  32. "How to JIT – an introduction", Eli Bendersky, November 5th, 2013 at 5:59 am
  33. De Mooij, Jan. "W^X JIT-code enabled in Firefox". Jan De Mooij. Retrieved 11 May 2016.


ग्रन्थसूची


बाहरी संबंध