2008-09-18 14 views
12

क्या जावा आभासी मशीन कभी भी स्मृति में वस्तुओं को स्थानांतरित करती है, और यदि ऐसा है, तो यह स्थानांतरित ऑब्जेक्ट को संदर्भों को अद्यतन करने में कैसे संभालता है?क्या जावा वीएम स्मृति में वस्तुओं को स्थानांतरित करता है, और यदि ऐसा है - कैसे?

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

मेरे दो विचारों अब तक कर रहे हैं:

  1. एक संदर्भ अविवेक कहीं उस वस्तु की जीवन भर है, जो हम अगर वस्तु चाल को अद्यतन के लिए स्थानांतरित नहीं होता है बनाए रखें। लेकिन - इन संकेतों को कैसे प्रबंधित किया जाता है?
  2. प्रत्येक ऑब्जेक्ट के साथ रिवर्स-रेफरेंस की एक सूची रखें, इसलिए हम जानते हैं कि ऑब्जेक्ट स्थानांतरित होने पर क्या अपडेट किया जाना है। बेशक, यह एक प्रदर्शन ओवरहेड बनाता है।

मुझे इन दृष्टिकोणों पर प्रतिक्रिया में रुचि होगी, और वैकल्पिक दृष्टिकोण के लिए कोई सुझाव होगा।

उत्तर

11

ढेर चलने के बारे में ऊपर टिप्पणी के संदर्भ में।

विभिन्न जीसी इसे अलग-अलग तरीके से करते हैं।

आमतौर पर ढेर चलते समय संग्राहक की प्रतिलिपि बनाते हैं, वे ढेर में सभी वस्तुओं को नहीं चलते हैं। इसके बजाय वे लाइव वस्तुओं को ढेर में चलते हैं। निहितार्थ यह है कि यदि यह "रूट" ऑब्जेक्ट से पहुंच योग्य है, तो ऑब्जेक्ट लाइव है।

इसलिए, इस चरण में सभी जीवित वस्तुओं को किसी भी तरह से छूना है, क्योंकि यह उन्हें पुराने ढेर से नए ढेर तक कॉपी करता है। एक बार जीवित वस्तुओं की प्रतिलिपि हो जाने के बाद, पुराने ढेर में जो भी रहता है, वह वस्तुएं पहले से ही कॉपी की गई हैं, या कचरा है। उस समय पुराने ढेर को पूरी तरह से त्याग दिया जा सकता है।

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

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

यह जीसी यांत्रिकी के बारे में गहराई से बात करने का मंच नहीं है, क्योंकि यह एक गैर-मामूली समस्या है, लेकिन यह मूलभूत बात है कि एक प्रतिलिपि संग्रहकर्ता कैसे काम करता है।

एक पीढ़ी की प्रतिलिपि जीसी अलग-अलग ढेर में "पुरानी" वस्तुओं को रखेगी, और अंततः "नए" ढेर से कम एकत्रित की जा रही है। सिद्धांत यह है कि लंबे समय तक चलने वाली वस्तुओं को पुरानी पीढ़ियों में बढ़ावा दिया जाता है और कुल मिलाकर जीसी प्रदर्शन में सुधार, कम और कम एकत्रित किया जाता है।

3

(व्यावहारिक रूप से) किसी भी कचरा एकत्रित प्रणाली को स्मृति में चारों ओर वस्तुओं को स्थानांतरित करना होता है ताकि उन्हें अधिक घनत्व से पैक किया जा सके और विखंडन की समस्याओं से बचा जा सके।

जो आप देख रहे हैं वह एक बहुत बड़ा और जटिल विषय है। मेरा सुझाव है कि आप मौजूदा रिमोट ऑब्जेक्ट स्टाइल एपीआई पर पढ़ लेंगे: .NET रीमोटिंग और CORBA

संदर्भों को ट्रैक करने के लिए कोई भी समाधान वितरित करने में मौजूद सभी विफलता मोड से निपटने के लिए जटिल होगा सिस्टम। JVM को अचानक यह पता लगाने की चिंता करने की ज़रूरत नहीं है कि यह अपने ढेर के आधे हिस्से को नहीं देख सकता क्योंकि नेटवर्क स्विच गड़बड़ हो गया है।

जब आप डिज़ाइन में ड्रिल करते हैं तो मुझे लगता है कि आप इसमें से बहुत कुछ विफल हो जाएंगे कि आप विभिन्न विफलता मामलों को कैसे संभालना चाहते हैं।

टिप्पणी करने के लिए उत्तर:

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

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

हालांकि, कचरा संग्रहण के लिए मूल विचार है:

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

इस प्रक्रिया के परिष्करण के रूप में वीएम पीढ़ी के कचरा संग्रह कर सकता है, जहां एक वस्तु के 'आयु' के आधार पर अलग-अलग ढेर बनाए रखा जाता है। ऑब्जेक्ट्स ढेर 0 में शुरू होते हैं और यदि वे कई जीसी जीवित रहते हैं तो माइग्रेट 1 को ढेर करने के लिए और अंततः 2 ढेर करने के लिए माइग्रेट करें (और इसी तरह - .NET केवल 3 पीढ़ियों का समर्थन करता है)। इसका लाभ यह है कि जीसी ढेर 0 संग्रहों को बहुत बार चला सकता है, और लंबी जीवित वस्तुओं को साबित करने के लिए काम करने के बारे में चिंता करने की ज़रूरत नहीं है (जो ढेर में समाप्त हो गया है) अभी भी जीवित हैं (जो वे लगभग निश्चित रूप से हैं) ।

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

+0

मैं ईमानदारी से .NET रिमोटिंग और कोर्बा की प्रासंगिकता को नहीं देख सकता। क्या आप अधिक विशिष्ट पॉइंटर्स प्रदान कर सकते हैं? – sanity

+0

इसके अलावा, वास्तव में जो मैं खोज रहा हूं वह यह है कि कैसे * कचरा एकत्रित सिस्टम ऑब्जेक्ट्स को चारों ओर स्थानांतरित करता है। – sanity

+0

@ सनीटी - रोब वाकर उन प्रौद्योगिकियों को उनकी रणनीतियों को बेहतर ढंग से समझने के साधनों के रूप में सिफारिश कर रहा है कि वे क्यों और कैसे करते हैं। –

2

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

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

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

+0

दिलचस्प, मैं इसकी जांच करूंगा। लेकिन, क्या किसी ऑब्जेक्ट के संदर्भों के लिए पूरे ढेर को खोजना बेहद अक्षम नहीं है? – sanity

+0

हां और नहीं। एक अर्थ में "मार्क" चरण को वैसे भी करना है, यह पता लगाने के लिए कि क्या ऑब्जेक्ट को नष्ट करने की योजना है या नहीं, संदर्भित किया गया है। तो सैकड़ों आदमी-वर्ष काम बढ़ते कचरा कलेक्टरों को अनुकूलित करने में चले गए हैं, ताकि वे सभी एक ही बार में ऐसा करने से बच सकें। –

1

लगता है जैसे आप एक वितरित कैश की तलाश में हैं, जैसे टेराकोटा या ओरेकल के जावा ओबेज कैश (पूर्व में टैंगर्सोल)।

+0

मुझे लगता है कि जिस उत्पाद को आप रेफर कर रहे हैं उसे "कोहेरेंस" कहा जाता है और कंपनी टैंगोसोल थी – Tnilsson

3

मैं आपकी आवश्यकताओं के बारे में और जानना चाहता हूं। जैसा कि एक और जवाब से पता चलता है, टेराकोटा बिल्कुल वही हो सकता है जो आप खोज रहे हैं।

हालांकि टेराकोटा प्रदान करता है, और आप जो पूछ रहे हैं, उसके बीच एक सूक्ष्म अंतर है, इस प्रकार मेरी पूछताछ।

अंतर यह है कि जहां तक ​​आप चिंतित हैं, टेराकोटा वस्तुओं के "रिमोट" संदर्भ प्रदान नहीं करता है - असल में आरआरआई, जेएमएस आदि की पूरी "रिमोट" धारणा टेराकोटा का उपयोग करते समय पूरी तरह से अनुपस्थित है।

इसके बजाय, टेराकोटा में, सभी वस्तुएं बड़े आभासी ढेर में रहते हैं। थ्रेड, चाहे नोड 1, या नोड 2, नोड 3, नोड 4, आदि पर सभी वर्चुअल ढेर में किसी ऑब्जेक्ट तक पहुंच हो।

सीखने के लिए कोई विशेष प्रोग्रामिंग नहीं है, या विशेष एपीआई, "वर्चुअल" ढेर में ऑब्जेक्ट्स स्थानीय ढेर में ऑब्जेक्ट्स के समान व्यवहार करते हैं।

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

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

तो सवाल आपके लिए वापस आने के लिए वापस आता है - आपको "रिमोट" पॉइंटर्स के किस उद्देश्य के लिए?

0

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

यह वही नहीं है जो आपने वर्णित किया है, लेकिन यह बहुत समान काम करता है।

यहां लिंक है।

http://www.jboss.org/jbosscache/

मुझे आशा है कि इस मदद करता है।

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

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