जेवीएम डिजाइन निर्णय

Question

जेवीएम को सरल हैलो दुनिया के लिए लगभग 10 एमबी मेमोरी की आवश्यकता क्यों है लेकिन क्लियर नहीं करता है। यहां व्यापार-बंद क्या है, यानी यह करने से जेवीएम लाभ क्या होता है?

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

Answer 1

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

जावा हमेशा जोर देता है कि इसकी पूरी लाइब्रेरी "लिंक्ड" और उपलब्ध है। चूंकि यह डीएलएल का उपयोग नहीं करता है (वे प्रत्येक प्लेटफार्म पर उपलब्ध नहीं होंगे), जावा द्वारा सबकुछ लोड और ट्रैक किया जाना चाहिए।

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

तो यदि आप सभी सामानों के बारे में सोचते हैं तो सी # ओएस में प्रतिनिधि हो सकता है, यह ओएस के लिए दूसरों को क्षतिपूर्ति करने के लिए ओएस के लिए सभी चीजों को बनाकर बांधता है, अंतर की उम्मीद की जानी चाहिए।

मैंने अब 2 एम्बेडेड प्लेटफ़ॉर्म पर जावा ऐप्स चलाए हैं। एक स्पेक्ट्रम विश्लेषक था जहां उसने वास्तव में निशान खींचा, दूसरा सेट टॉप केबल बॉक्स है।

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

Answer 2

CLR ओएस के भाग के रूप में गिना जाता है।

Answer 3

JVM अपने सभी साझा पुस्तकालयों में गिना जाता है कि क्या वे स्मृति नहीं का उपयोग करें या।

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

Answer 4

लगता है जैसे जावा बस अधिक आभासी स्मृति का उपयोग कर रहा है।

USER  PID %CPU %MEM VSZ RSS TTY  STAT START TIME COMMAND 
amwise 20598 0.0 0.5 22052 5624 pts/3 Sl+ 14:59 0:00 mono Test.exe 
amwise 20601 0.0 0.7 214312 7284 pts/2 Sl+ 15:00 0:00 java Program 

मैंने सी # और जावा में एक परीक्षण कार्यक्रम बनाया जो स्ट्रिंग "टेस्ट" प्रिंट करता है और इनपुट के लिए इंतजार करता है। मेरा मानना ​​है कि निवासी सेट आकार (आरएसएस) मूल्य अधिक सटीक रूप से स्मृति उपयोग दिखाता है। आभासी स्मृति उपयोग (वीएसजेड) कम सार्थक है।

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

संपादित करें: alt text http://awise.us/images/mem.png

प्रत्येक ऐप में एक सरल एक getchar के बाद printf था:

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

मुझे संदेह है कि यह वास्तव में किसी भी तरह से मायने रखता है। बस जो भी मंच आप अधिक परिचित हैं उसे चुनें और फिर भयानक, स्मृति-बर्बाद कोड न लिखें। मुझे यकीन है कि यह काम करेगा।

संपादित करें:

Microsoft से इस VMMap tool बाहर figureing जहां स्मृति जा रहा है में उपयोगी हो सकता है।

Answer 5

मुझे नहीं पता कि प्रारंभिक मेमोरी पदचिह्न या हैलो वर्ल्ड एप्लिकेशन का पदचिह्न महत्वपूर्ण है या नहीं। एक अंतर JVM/CLR द्वारा लोड की गई पुस्तकालयों की संख्या और आकार के कारण हो सकता है। कचरा संग्रहण पूल के लिए पहले से मौजूद स्मृति की मात्रा भी हो सकती है।

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

http://benpryor.com/blog/2006/05/04/jvm-vs-clr-memory-allocation/

Memory Management Case study (JVM & CLR)

मेमोरी मैनेजमेंट मामले का अध्ययन पावर प्वाइंट में है के साथ लिंक की एक जोड़ी है। एक बहुत ही रोचक प्रस्तुति।

Answer 6

जेवीएम rt.jar से प्रत्येक रन पर बहुत सारे अनावश्यक कोर कक्षाओं को लोड करता है। दुर्भाग्यवश, जावा संकुल के आंतरिक-पार निर्भरता (java.lang < -> java.io) आंशिक रनटाइम init करने में कठिनाई होती है। उल्लेख नहीं है कि rt.jar खुद 40 एमबी से अधिक है, लुकअप और डिकंप्रेस के लिए बहुत समय की जरूरत है।

पोस्ट जावा 6u10 चीजों को थोड़ा अधिक स्मार्ट लोड करने लगता है (इसमें एक jqs.exe = जावा त्वरित स्टार्टर सेवा है जो स्मृति में आवश्यक डेटा रखने और तेज स्टार्टअप करने के लिए) है, फिर भी जावा 7 को बेहतर बताया जाता है।

Windows में प्रोसेस एक्सप्लोरर सही ढंग से निजी बाइट्स रिपोर्ट (निजी बाइट्स उन स्मृति क्षेत्रों, जो किसी भी dll द्वारा साझा नहीं कर रहे हैं)।

एक थोड़ा बड़ा झुंझलाहट है कि 10 साल के बाद, JVM अभी भी 64MB स्मृति के उपयोग करने के लिए चूक। यह लगभग हर बार -Xmx उपयोग करने के लिए और एक साधारण डबल क्लिक के साथ जार में कार्यक्रमों की मांग नहीं चला सकते हैं (जब तक मैं फाइल एक्सटेंशन काम के आदेश को बदल) वास्तव में कष्टप्रद है।