2008-09-12 18 views
17

जावा के जेवीएम और .NET के सीएलआर के आंतरिक कार्यों के बीच क्या अंतर है?जावा के जेवीएम और .NET के सीएलआर के आंतरिक कार्यों के बीच क्या अंतर है?

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


अद्यतन:

  1. कूड़ा संग्रह
  2. मुक्केबाजी/अनबॉक्सिंग
  3. JIT डीबगिंग
  4. जेनेरिक्स/खाके
  5. :
    कई लोगों ने अंक मैं कवर करने के लिए कोशिश कर रहा था उल्लेख किया है
  6. कृपया अन्य अच्छे विषयों का सुझाव देने के लिए स्वतंत्र महसूस करें जो अलग-अलग हैं दो।

@George Mauer - यह बहुत दिलचस्प लगता है:

पहले से ही एक बार इस पोस्ट लेकिन यहाँ C# मुख्य भाषा डिजाइनर एंडर्स हेल्स्बर्ग के साथ एक series of interviews है।

+0

मैं इस विषय का संदर्भ देने वाले विषय के साथ एक नया प्रश्न शुरू करने का सुझाव देता हूं। –

उत्तर

5

पहले से ही ग # मुख्य भाषा डिजाइनर एंडर्स हेल्स्बर्ग के साथ एक बार लेकिन here is a series of interviews इस पोस्ट की। ज्यादातर सी # और जावा के बीच मतभेद के बारे में बात हालांकि वह करता है आभासी मशीनों के बीच मतभेद में गोता के रूप में अच्छी तरह से।

+0

मुझे इस लड़के को मेरे स्कूल में बोलने का मौका मिला और मैंने इसे उड़ा दिया। वास्तव में अब पछतावा है। –

6

here से। मैं इसे बेहतर नहीं कह सकता था (ठीक है, लौ युद्ध के अपवाद के साथ, यह एक निर्बाध जगह है :-))।

हैलो,

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

कचरा एकत्र स्मृति, एक मध्यवर्ती भाषा (जावा बाईटकोड बनाम माइक्रोसॉफ्ट IL), कोर प्रणाली पुस्तकालयों और सहायता शामिल जावा रनटाइम और सामान्य भाषा क्रम के बीच मौलिक तकनीकी समानता के एक नंबर, रहे हैं के लिए काफी उच्च स्तर की भाषाएं, कोड सुरक्षा, और तैनाती।

हालांकि, इन 'समान' क्षेत्रों में से प्रत्येक भी बड़े आकार का और छोटे मतभेद की एक संख्या है, और यह के लिए एक सरल फोरम पोस्ट के दायरे से परे है उनमें से ज्यादातर का वर्णन।

मैं विभिन्न क्रम सुविधाओं और घटक क्षेत्रों (जैसे स्मृति प्रबंधन, संकलन, प्रणाली पुस्तकालयों, सुरक्षा, आदि) और से किसी के बारे में एक और अधिक लक्षित प्रश्न पूछ तो हम एक और अधिक प्रदान कर सकते हैं सुझाव है कि लक्षित प्रतिक्रिया (उदाहरण के लिए एक ब्लॉग, एक तकनीकी लेख, या कुछ किताबें)।

9

यह एक महान धागा होना चाहिए।

सबसे बड़ी अंतर यह है CLR के बीच है और JVM CLR "रों जेनरिक के देशी एकीकरण है।

जावा के बजाय सामान्य प्रकार दूर करता है और JVM केवल वस्तुओं के लिए यह प्रतीत होता है autoboxing द्वारा वस्तुओं के साथ काम कर सकते हैं छद्म जेनरिक हो।

+1

के आसपास विशेषज्ञ होने पर इस तरह से प्रत्येक विषय को अधिक गहराई से कवर किया जा सकता है। टाइप मिरर बहुत महत्वपूर्ण है, मैंने सोचा। –

0

Vinko के रूप में कहा, पूरा विवरण रास्ता है एक मंच पोस्ट के दायरे से परे। मतभेद/समानताएं इस पर उबाल लें:

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

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

1

Miguel de Icaza here का उल्लेख है:

अनुभवी उद्योग प्रोग्रामर देखेंगे कि इसके बाद के संस्करण बहुत ज्यादा जावा और जावा वी एम की तरह है। वे सही हैं, ऊपर जावा की तरह ही है।

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

मेरी इच्छा है कि मेरे पास अधिक विस्तार से जाने का समय हो, लेकिन इस तर्क के के लिए उपर्युक्त पर्याप्त होगा।

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

+0

एचएम ... मुझे यकीन नहीं है कि यह काफी प्रासंगिक है, और कम से कम आजकल (उत्तर 2 साल पहले पोस्ट किया गया था)। अभी के लिए हमारे पास क्लोजर है, जो लिस्प की बोली है, और अभी भी राइनो (जो एक जावास्क्रिप्ट है) है, और ग्रोवी और स्कैला जैसी कई भाषाएं हैं। – 0100110010101

+0

पूंछ-कॉल अनुकूलित करने या चीजों को इनलाइन करने के तरीके के बारे में सवाल एक दिलचस्प है, क्योंकि वास्तविकता का प्रतिनिधित्व करने की गारंटी देने वाले स्टैकट्रैक होने के कुछ फायदे हो सकते हैं। कॉल के रूप में एक स्टैक ट्रेस पर आने के लिए रेखांकित दिनचर्या का कारण बनने के लिए मेटाडेटा का उपयोग किया जा सकता है, लेकिन पूंछ कॉल को घोंसले के स्तर को ट्रैक रखने के लिए जेनरेट कोड की आवश्यकता होगी। उस उद्देश्य के लिए स्थानीय चर का उपयोग करना नेस्टेड 'कॉल' निर्देशों का उपयोग करने से सस्ता हो सकता है, लेकिन तब किसी को यह तय करना होगा कि स्टैक ट्रेस पर इसका प्रतिनिधित्व कैसे किया जाए। यदि रिकर्सिव गहराई वास्तविक स्टैक तक सीमित है ... – supercat

+0

... जो एक स्टैक ट्रेस कितनी देर तक प्राप्त कर सकती है, इस पर उचित सीमा डालती है। इसके विपरीत, यदि कोई दिनचर्या पूंछ-कॉल लाखों स्तरों को गहरा कर सकती है, तो उन कॉलों को एक स्टैक ट्रेस में विस्तारित करना बेतुका होगा। – supercat

2

एक आवश्यक अंतर यह है कि जेवीएम प्लेटफॉर्म पर पोर्टेबल है और लिनक्स, मैकिंटोश, और कई सेल फोन और एम्बेडेड डिवाइस पर चलता है।

सीएलआर मोनो प्रोजेक्ट के साथ माइक्रोसॉफ्ट समर्थित प्लेटफ़ॉर्म पर चलता है जो कुछ और पर सीएलआर के पुराने संस्करणों का आंशिक समर्थन प्रदान करता है।

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

+0

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

+0

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

0

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

-1

कचरा संग्रह में भी अंतर है। जेवीएम कलेक्टर कॉपी और मार्क और स्वीप का उपयोग करता है। .NET उपयोगकर्ता कलेक्टर और मार्क और कॉम्पैक्ट की प्रतिलिपि बनाना (लागू करने के लिए बहुत कठिन)।

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

2

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

एक अच्छा उदाहरण स्टैक आवंटन है। सीएलआर पर आपके पास कस्टम मूल्य प्रकारों के स्पष्ट ढेर आवंटन हैं। JVM पर केवल कस्टम प्रकार संदर्भ प्रकार हैं लेकिन JVM एस्केप विश्लेषण के माध्यम से कुछ परिस्थितियों में आवंटन को ढेर करने के लिए ढेर आवंटन को परिवर्तित कर सकता है।

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

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

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

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

संबंधित मुद्दे