कचरा संग्रह और धागे

Question

AFAIK जब कोई जीसी अपनी बात कर रहा है तो वीएम सभी चल रहे धागे को अवरुद्ध करता है - या कम से कम जब यह ढेर को संकुचित कर रहा है। क्या यह सीएलआर के आधुनिक कार्यान्वयन और JVM (जनवरी 2010 के रूप में उत्पादन संस्करण) है? कृपया जीसी पर बुनियादी लिंक प्रदान न करें क्योंकि मैं प्राथमिक कार्यप्रणाली को समझता हूं।

मुझे लगता है कि वैश्विक लॉकिंग यह है कि जब संकलन होता है तो संदर्भ अवधि के दौरान अमान्य हो सकता है, और पूरे ढेर को लॉक करने के लिए यह सबसे आसान लगता है (यानी, सभी धागे को अवरुद्ध करके अप्रत्यक्ष रूप से)। मैं और अधिक मजबूत तंत्र की कल्पना कर सकता हूं, लेकिन केआईएसएस अक्सर प्रचलित होता है।

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

1. अगर यह वास्तव में व्यवहार है, कैसे JBoss और Glassfish तरह हैवीवेट उद्यम इंजन एक consistantly उच्च टीपीएस दर बनाए रखते हैं? मैंने जेबीओएसएस पर कुछ googling किया था और मैं वेब प्रसंस्करण के लिए अनुकूल स्मृति आवंटक की तरह एक एपैच पर कुछ खोजने की उम्मीद कर रहा था।

2. NUMA-esque आर्किटेक्चर (संभावित रूप से निकट भविष्य) के चेहरे में यह एक आपदा की तरह लगता है जब तक प्रक्रिया सीपीयू थ्रेड और मेमोरी-आवंटन से बंधी न हो।

Answer 1

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

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

यदि मैं गलत हूं तो मेरे प्रश्न का उत्तर ब्लॉकिंग को कम करने के लिए उपयोग की जाने वाली रणनीति के सरल स्पष्टीकरण द्वारा दिया जाएगा।

तुम सच को समझने के लिए कचरा कलेक्टरों काम चाहते हैं, मेरा सुझाव है: रिचर्ड जोन्स द्वारा

• "Garbage Collection: Algorithms for Automatic Dynamic Memory Management"
• "The Garbage Collection Handbook: The Art of Automatic Memory Management" द्वारा रिचर्ड जोन्स, एंटनी Hosking और एलियट मॉस

।

... और सावधान रहें कि उत्पादन कचरा कलेक्टरों के आंतरिक के सटीक, विस्तृत, सार्वजनिक विवरण ढूंढना आसान नहीं है। (तू हॉटस्पॉट जीसी के मामले में, आप स्रोत कोड देख सकते हैं ...)

संपादित करें: ओपी की टिप्पणी के जवाब में ...

"ऐसा लगता है जैसे मैंने सोचा -" दुनिया को रोकें "भाग के आसपास नहीं हो रहा है।"

यह निर्भर करता है। Java 6 Concurrent Collector के मामले में, जड़ें (ढेर सहित) के अंकन के दौरान दो विराम होते हैं, और उसके बाद समानांतर में अन्य ऑब्जेक्ट आय की अंकन/प्रतिलिपि बनाते हैं। अन्य प्रकार के समवर्ती संग्राहक के लिए, बाधाओं को पढ़ने या लिखने के लिए उपयोग किया जाता है जबकि कलेक्टर जाल स्थितियों में चल रहा है जहां संग्राहक और अनुप्रयोग धागे अन्यथा एक दूसरे के साथ हस्तक्षेप करेंगे। मेरे पास अभी [जोन्स] की मेरी प्रति नहीं है, लेकिन मुझे यह भी याद है कि "दुनिया को रोकना" अंतराल नगण्य बनाना संभव है ... अधिक महंगा सूचक संचालन की लागत पर और/या सभी एकत्र नहीं करना कचरा।

Answer 2

जावा के साथ कई जीसी एल्गोरिदम उपलब्ध हैं, जिनमें से सभी सभी चल रहे धागे को अवरुद्ध नहीं करते हैं। उदाहरण के लिए, आप -XX: + UseConcMarkSweepGC का उपयोग कर सकते हैं जो ऐप के साथ समवर्ती रूप से चलता है (कार्यरत पीढ़ी के संग्रह के लिए)।

Answer 3

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

यहां देखें http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc और यहां http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#cms इस बारे में विवरण के लिए कि कैसे सूर्य JVM नवीनतम JVMs में कचरा संग्रह प्रबंधित करता है।

वेब अनुप्रयोगों के लिए मुझे नहीं लगता कि यह एक मुद्दा है। चूंकि उपयोगकर्ता अनुरोधों को थोड़ी देर के भीतर पूरा करना चाहिए < 1s सेवा के लिए आवंटित किसी भी अस्थायी वस्तु को अनुरोध को युवा पीढ़ी से बाहर नहीं निकलना चाहिए (इसे उचित रूप से आकार दिया जाना चाहिए) जहां उन्हें बहुत कुशलता से साफ किया जाता है। उपयोगकर्ता सत्र जैसे लंबे जीवनशैली वाले अन्य डेटा लंबे समय तक लटकाएंगे और प्रमुख जीसी कार्यक्रमों पर खर्च किए गए समय को प्रभावित कर सकते हैं।

उच्च टीपीएस अनुप्रयोगों पर एक सामान्य रणनीति अनुप्रयोग सर्वर के कई उदाहरणों को या तो सत्र एफ़िनिटी और लोड बैलेंसिंग का उपयोग कर एक ही या अलग हार्डवेयर पर चलाने के लिए है। ऐसा करने से प्रति जेवीएम के व्यक्तिगत ढेर आकार को छोटा रखा जाता है जो एक बड़ा संग्रह करते समय जीसी के लिए विराम के समय को कम करता है। आम तौर पर डेटाबेस एप्लिकेशन या जेवीएम की बजाय बोतल गर्दन बन जाता है।

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

Answer 4

जावा के लिए कला कचरा संग्रह की वर्तमान स्थिति में अभी भी कभी-कभी "दुनिया को रोकें" विराम शामिल हैं। जावा 6u14 पर पेश किया गया जी 1 जीसी इसके अधिकांश कामों को समवर्ती रूप से करता है, हालांकि, जब स्मृति वास्तव में कम होती है, और इसे ढेर को कम करने की आवश्यकता होती है, तो उसे यह सुनिश्चित करना होगा कि कोई भी नीचे के ढेर के साथ गड़बड़ न करे। इसके लिए यह आवश्यक है कि आगे बढ़ने की अनुमति नहीं है। जी 1 जीसी के बारे में और जानने के लिए, presentations from Sun देखें।

Answer 5

मेरा मानना ​​है कि आईबीएम ने मल्टी-कोर सिस्टम में जीसी प्रदर्शन में सुधार के लिए कुछ शोध किया है जिसमें 'सब कुछ स्टॉप' मुद्दे को कम करने या समाप्त करने पर काम शामिल है।

उदा। देखें: A Parallel, Incremental and Concurrent GC for Servers(pdf)

या की तरह "समवर्ती कचरा संग्रहण आईबीएम"

Answer 6

AFAIK जब एक जीसी अपनी बात वीएम ब्लॉक चल रहे सभी धागे कर रहा है कुछ गूगल - जब यह ढेर संकुचित हो रहा है या कम से कम। क्या यह सीएलआर और जेवीएम (जनवरी 2010 के रूप में उत्पादन संस्करण) के आधुनिक कार्यान्वयन में मामला है?

दोनों सूर्य की हॉटस्पॉट JVM और माइक्रोसॉफ्ट के CLR है समवर्ती जेंटलमैन कैडेट रोक-दुनिया कि केवल छोटे चरणों के लिए (वैश्विक जड़ों से जो सभी को लाइव डेटा पहुंचा जा सकता है की एक आत्म-संगत स्नैपशॉट प्राप्त करने के लिए) और पूरे के लिए नहीं संग्रह चक्र मैं compaction के उनके कार्यान्वयन के बारे में निश्चित नहीं हूँ लेकिन यह एक बहुत ही दुर्लभ घटना है।

यदि यह वास्तव में व्यवहार है, तो जेबीएसएस और ग्लासफ़िश जैसे हेवीवेट एंटरप्राइज़ इंजन लगातार उच्च टीपीएस दर बनाए रखते हैं?

उन इंजनों की विलंबता दुनिया को रोकने के लिए किए गए समय से अधिक परिमाण का आदेश है। इसके अलावा, विलंबता को उद्धृत किया गया है, उदाहरण के लिए, 95 वें प्रतिशत का अर्थ है कि विलंबता समय के 9 5% समय के उद्धृत समय से कम होगी। तो उद्धरण उद्धृत विलंबता को प्रभावित करने की संभावना नहीं है।