वर्चुअल मशीनों की आवश्यकता क्यों है?

Question

मैं जावा वर्चुअल मशीन और .NET CLR और बेनजी के उत्तर के बीच अंतर जानने के लिए this question पढ़ रहा था और मुझे आश्चर्य हुआ कि पहली जगह वर्चुअल मशीनों की आवश्यकता क्यों है।

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

लेकिन, अगर ऐसा है, तो मुझे समझ में नहीं आता है कि मशीन कोड में संकलित सी या सी ++ कोड किसी भी कंप्यूटर पर तब तक चलने में सक्षम है जब तक कि यह सही ओएस न हो। फिर एक पेंटियम का उपयोग करके मेरी विंडोज मशीन पर संकलित एक सी प्रोग्राम क्यों एक एएमडी का उपयोग कर मेरी अन्य विंडोज मशीन पर चलाने में सक्षम हो जाएगा?

यदि सी कोड किसी भी CPU पर चलाया जा सकता है तो वर्चुअल मशीन का उद्देश्य क्या है? क्या ऐसा है कि किसी भी ओएस पर एक ही कोड चलाया जा सकता है? मुझे पता है कि जावा में बहुत अधिक ओएस पर वीएम संस्करण हैं लेकिन क्या विंडोज़ के अलावा अन्य ओएस के लिए सीएलआर है?

या क्या मुझे कुछ और याद आ रही है? क्या ओएस असेंबली कोड की कुछ अन्य व्याख्या करता है जो इसे विशेष CPU या कुछ अनुकूलित करने के लिए चलाता है?

मैं इस बारे में बहुत उत्सुक हूं कि यह सब कैसे काम करता है, इसलिए एक स्पष्ट स्पष्टीकरण की सराहना की जाएगी।

नोट: कारण मैंने जेवीएम बनाम सीएलआर प्रश्न में टिप्पणियों के रूप में मेरे प्रश्नों को पोस्ट नहीं किया है क्योंकि मेरे पास टिप्पणियां पोस्ट करने के लिए पर्याप्त अंक नहीं हैं = बी।

संपादित करें: सभी महान उत्तरों के लिए धन्यवाद! तो ऐसा लगता है कि मैं जो खो रहा था वह था कि हालांकि सभी प्रोसेसर में अंतर होता है, हालांकि एक सामान्य मानकीकरण होता है, मुख्य रूप से एक्स 86 आर्किटेक्चर, जो सामान्य सुविधाओं का एक बड़ा सेट प्रदान करता है ताकि एक एक्स 86 प्रोसेसर पर संकलित सी कोड अधिकांश भाग के लिए काम करेगा एक और X86 प्रोसेसर पर। यह वर्चुअल मशीनों के लिए औचित्य को आगे बढ़ाता है, उल्लेख नहीं है कि मैं कचरा संग्रह के महत्व के बारे में भूल गया हूं।

Answer 1

एएमडी और इंटेल प्रोसेसर एक ही निर्देश सेट और मशीन आर्किटेक्चर (मशीन कोड के निष्पादन के दृष्टिकोण से) का उपयोग करते हैं।

सी और सी ++ कंपाइलर मशीन कोड के लिए संकलित, ओएस के लिए उपयुक्त हेडर के साथ लक्षित हैं। एक बार संकलित हो जाने पर वे किसी भी तरह से, आकार, या फॉर्म को उस भाषा के साथ जोड़ना बंद कर देते हैं, जिसमें वे संकलित किए गए थे और केवल बाइनरी निष्पादन योग्य हैं। (कलाकृतियों taht दिखा सकते हैं कि यह किस भाषा से संकलित किया गया था, लेकिन यह यहां बिंदु नहीं है)

तो एक बार संकलित, वे मशीन (X86, इंटेल और एमडीडी निर्देश सेट और आर्किटेक्चर) से जुड़े हुए हैं और ओएस

यही कारण है कि वे किसी भी संगत x86 मशीन पर चल सकते हैं, और किसी भी संगत ओएस (कुछ सॉफ्टवेयर के लिए Winvista के माध्यम से win95) चला सकते हैं।

हालांकि, वे एक ओएसएक्स मशीन पर नहीं चल सकते हैं, भले ही यह एक इंटेल प्रोसेसर पर चल रहा हो - बाइनरी तब तक संगत नहीं है जब तक आप अतिरिक्त इम्यूलेशन सॉफ़्टवेयर (जैसे समानांतर, या विंडोज़ के साथ वीएम) चलाते हैं।

इसके अलावा, यदि आप उन्हें एआरएम प्रोसेसर, या एमआईपीएस, या पावरपीसी पर चलाने के लिए चाहते हैं, तो आपको एक पूर्ण मशीन निर्देश सेट एमुलेटर चलाने की ज़रूरत है जो X86 से बाइनरी मशीन कोड को जो भी मशीन आप चला रहे हैं चालू करो।

कंट्रास्ट कि .NET के साथ।

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

अचानक आप किसी भी प्रोसेसर के लिए एक मशीन विशिष्ट एमुलेटर लिख सकते हैं जिसे आप चलाने के लिए चाहते हैं .NET चालू करें, और उसके बाद कोई भी .NET प्रोग्राम चलाया जा सकता है। ओएस या अंतर्निहित CPU आर्किटेक्चर के बारे में चिंता करने की आवश्यकता नहीं है - यदि कोई .NET VM है, तो सॉफ़्टवेयर चलाएगा।

लेकिन चलिए थोड़ा आगे जाते हैं - एक बार जब आप यह आम भाषा रखते हैं, तो क्यों कंपेलर नहीं बनाते हैं जो किसी अन्य लिखित भाषा को परिवर्तित करते हैं?

तो अब आपके पास सी, सी #, सी ++, जावा, जावास्क्रिप्ट, बेसिक, पायथन, लुआ, या कोई अन्य भाषा कंपाइलर हो सकता है जो लिखित कोड को परिवर्तित करता है ताकि यह इस वर्चुअल मशीन पर चलेगा।

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

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

ऑटोकैड प्रत्येक प्रिंटर वे पर प्रिंट कर सकता है के लिए ड्राइवरों लिखना पड़ा । तो कमल 1-2-3 किया था।वास्तव में, यदि आप अपने सॉफ्टवेयर को प्रिंट करना चाहते थे, तो आपको अपने ड्राइवर लिखना पड़ा। यदि 10 प्रिंटर और 10 प्रोग्राम थे, तो अनिवार्य रूप से एक ही कोड के 100 अलग-अलग टुकड़े अलग-अलग और स्वतंत्र रूप से लिखे जाने थे।

क्या विंडोज 3.1 ने पूरा करने की कोशिश की (जीईएम, और कई अन्य अमूर्त परतों के साथ) इसे प्रिंटर निर्माता ने अपने प्रिंटर के लिए एक ड्राइवर लिखा है, और प्रोग्रामर ने विंडोज प्रिंटर क्लास के लिए एक ड्राइवर लिखा है।

अब 10 प्रोग्राम और 10 प्रिंटर के साथ, कोड के केवल 20 टुकड़े लिखे जाने चाहिए, और चूंकि कोड का माइक्रोसॉफ्ट पक्ष हर किसी के लिए समान था, तो एमएस के उदाहरणों का मतलब था कि आपके पास बहुत कम काम था।

अब एक प्रोग्राम केवल 10 प्रिंटर तक ही सीमित नहीं था, जिसे उन्होंने समर्थन देने के लिए चुना था, लेकिन सभी प्रिंटर जिनके निर्माताओं ने विंडोज़ में ड्राइवरों को प्रदान किया था।

एप्लिकेशन विकास में एक ही समस्या हो रही है। वास्तव में साफ अनुप्रयोग हैं जिनका उपयोग मैं नहीं कर सकता क्योंकि मैं मैक का उपयोग नहीं करता हूं। नकल का एक टन है (हमें वास्तव में कितने विश्व स्तरीय वर्ड प्रोसेसर की ज़रूरत है?)।

जावा इसे ठीक करने के लिए था, लेकिन इसमें कई सीमाएं थीं, जिनमें से कुछ वास्तव में हल नहीं हुई हैं।

.NET करीब है, लेकिन विंडोज़ के अलावा प्लेटफॉर्म के लिए कोई भी विश्व स्तरीय वीएम विकसित नहीं कर रहा है (मोनो बहुत करीब है ... और अभी तक काफी नहीं है)।

तो ... यही कारण है कि हमें वीएम की आवश्यकता है। क्योंकि मैं खुद को एक छोटे से दर्शकों तक सीमित नहीं करना चाहता क्योंकि उन्होंने ओएस/मशीन संयोजन को स्वयं से अलग किया है।

-Adam

Answer 2

एएमडी और इंटेल प्रोसेसर दोनों में x86 आर्किटेक्चर है, यदि आप एक अलग आर्किटेक्चर पर सी/सी ++ प्रोग्राम चलाने के लिए चाहते हैं तो आपको उस आर्किटेक्चर के लिए एक कंपाइलर का उपयोग करना होगा, उसी बाइनरी निष्पादन योग्य विभिन्न प्रोसेसर आर्किटेक्चर में नहीं चलेगा।

Answer 3

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

Answer 4

मुझे पता है कि जावा में वीएम संस्करण बहुत अधिक ओएस पर हैं लेकिन क्या विंडोज़ के अलावा अन्य ओएस के लिए सीएलआर है?

Mono

Answer 5

एक बहुत ही सरल तरीके से, कि क्योंकि इंटेल और एएमडी एक ही विधानसभा भाषा को लागू करता है, रजिस्टर के एक ही नंबर, आदि आदि के साथ है ...

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

अब उस संकलित कोड को लेने का प्रयास करें, और इसे चिपकाएं, लिनक्स/पीपीसी (उदाहरण के लिए पुराने आईबुक पर लिनक्स) कहें। वह काम नहीं करेगा। जहां जावा प्रोग्राम होगा क्योंकि जेवीएम को लिनक्स/पीपीसी मंच पर लागू किया गया है।

असेंबली लैंगेज आजकल मूल रूप से एक और इंटरफ़ेस है जो प्रोग्रामर प्रोग्राम कर सकता है। x86 (32-बिट) आपको सामान्य उद्देश्य पूर्णांक रजिस्ट्रार के लिए ईएक्स, ईबीएक्स, एक्क्स, एडक्स तक पहुंचने और फ्लोटिंग पॉइंट के लिए f00-f07 तक पहुंचने की अनुमति देता है। दृश्यों के पीछे, सीपीयू में वास्तव में सौ और रजिस्ट्रार हैं, और प्रदर्शन के निचोड़ने के लिए उस सामान को झुका दिया।

Answer 6

आपकी धारणा है कि किसी भी प्रोसेसर पर सी कोड चलाया जा सकता है गलत है। रजिस्टरों और अंतहीनता जैसी चीजें हैं जो संकलित सी प्रोग्राम एक मंच पर बिल्कुल काम नहीं करतीं, जबकि यह किसी अन्य पर काम कर सकती है।

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

क्यों आप एक वर्चुअल मशीन चाहते हैं, यह बयान से परे कि यह आपके लिए प्रोसेसर में मतभेदों को संभालेगा, यह भी तथ्य है कि वर्चुअल मशीन कोड को सेवाएं प्रदान करती हैं जो सी ++ में संकलित प्रोग्रामों के लिए उपलब्ध नहीं हैं (नहीं प्रबंधित) आज।

सीएलआर और जेवीएम द्वारा पेश की जाने वाली सबसे प्रमुख सेवा कचरा संग्रह है। इन दोनों वर्चुअल मशीनें आपको यह सेवा मुफ्त में प्रदान करती हैं। वे आपके लिए स्मृति का प्रबंधन करते हैं।

सीमाओं की जांच जैसी चीजें, उल्लंघन का उल्लंघन (हालांकि अभी भी संभव है, वे बेहद मुश्किल हैं) भी पेश किए जाते हैं।

सीएलआर आपके लिए कोड सुरक्षा का एक रूप भी प्रदान करता है।

इनमें से कोई भी वर्चुअल मशीन के साथ संचालित नहीं होने वाली कई अन्य भाषाओं के लिए मूल रनटाइम पर्यावरण के हिस्से के रूप में पेश किया जाता है।

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

Answer 7

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

केवल समय-समय पर संकलन के लिए, वर्चुअल मशीन कोड निष्पादित करती है और इसलिए कोड अधिक बार चलाया जाता है, इसे तेज़ी से चलाने के लिए दोबारा शुरू किया जाता है। आप मूल कोड के साथ ऐसा नहीं कर सकते हैं।

प्रबंधित पॉइंटर्स को अनुकूलित करना भी आसान है क्योंकि आभासी मशीन उन्हें ट्रैक करती है क्योंकि वे चारों ओर जाते हैं, उन्हें अपने आकार और जीवनकाल के आधार पर विभिन्न तरीकों से प्रबंधित करते हैं। सी ++ में ऐसा करना मुश्किल है क्योंकि आप वास्तव में यह नहीं बता सकते कि एक पॉइंटर कोड पढ़ने के लिए कहां जा रहा है।

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

मूल रूप से मेरा बिंदु है, क्योंकि वर्चुअल मशीन कोड को देखकर देख सकती है, यह ऐसी चीजें कर सकती है जो प्रोग्रामर पर जीवन को आसान बनाती हैं और कोड को तेज़ी से बनाती हैं।

Answer 8

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

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

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

Answer 9

मुझे लगता है कि आपके प्रश्न का आधार मान्य है - आप निश्चित रूप से इस सवाल से पूछने वाले पहले व्यक्ति नहीं हैं। तो वैकल्पिक दृष्टिकोण देखने के लिए http://llvm.org देखें (जो अब एक प्रोजेक्ट चलाया जा रहा है या ऐप्पल द्वारा प्रायोजित)

Answer 10

अधिकांश कंपाइलर, यहां तक ​​कि देशी कोड कंपाइलर, कुछ प्रकार की इंटरमीडिएट भाषा का उपयोग करते हैं।

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

हालांकि, एक इंटरमीडिएट भाषा को परिभाषित करके और एक कंपाइलर को 2 भागों में तोड़कर, फ्रंट एंड एंड बैक एंड, आईएल में फ्रंट कोड संकलित स्रोत कोड और आईएल को मशीन कोड में संकलित करने के पीछे के अंत के साथ, आप प्राप्त कर सकते हैं केवल एन + एम कंपाइलर लिखने के साथ दूर। यह एक बड़ी लागत बचत होने के समाप्त होता है।

सीएलआर/जेवीएम कंपाइलर्स और देशी कोड कंपाइलर्स के बीच बड़ा अंतर सामने वाला अंत और बैक एंड कंपाइलर्स एक दूसरे से जुड़े हुए हैं। देशी कोड कंपाइलर में दो घटक आमतौर पर एक ही निष्पादन योग्य होते हैं, और दोनों प्रोग्रामर होते हैं जब प्रोग्रामर आईडीई में "बिल्ड" हिट करता है।

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

तो, यह वैकल्पिक सवाल उठाता है, "रनटाइम तक बैक एंड संकलन में देरी के लाभ क्या हैं"?

उत्तर है: "यह निर्भर करता है"।

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

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