~ 1s विलंबता नियंत्रण ऐप: क्या यह जावा के लिए उपयुक्त है?

Question

मेरे काम पर हमने हाल ही में एक नियंत्रण अनुप्रयोग के लिए सिस्टम आर्किटेक्चर समाप्त कर दिया है जिसमें लगभग एक से दो सेकंड की अधिकतम विलंबता है। यह एक आईपी लैन के माध्यम से संचारित छोटे एआरएम ऑन-चिप बॉक्स पर वितरित किया जाता है।

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

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

समर्थक/चोर सूची वर्तमान में इस प्रकार है:

C++ 

+ RAII - Easy resource management - it will be a complex system 
+ System language - speed if we cant't find a JIT VM for our ARM 
+ No GC - no big worst case latencies from the GC 
+ Easy to integrate with some shared mem libs that we have to interface with 
- Fewer free as in beer libs 
- Lacks introspection - Mapping classes to DB and external data formats (XML)  
    would benefit from this (ORM /JAXB) approach 
- Easy to shoot one self in the foot - hard and expensive to find programmers 
    which don't make big mistakes 
- Memory fragmentation - needs tuning and workarounds 

Java 

+ Huge amount of libs 
+ Introspection - serialization becomes a breeze (see C++ section) 
+ Easier to find 'good enough' programmers 
- No RAII - Client has to remember finally or you leak 
    resources. IMO Java programmers tend to ignore this 
    problem unless they have server app background. 
- No System Language - possibly slower although ARMj could alleviate this 
- GC - latency might go up (don't know if parallel GC will work - seems that 
    you might get fragmentation, see note below). 
- Need to write JNI for the shared mem libs that we interface with 
- Maybe ORACLE will eat us 

समानांतर जीसी के साथ स्मृति विखंडन उल्लेख किया गया था in this AMD article

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

तो, मेरा सवाल है: क्या आपके पास इस पर कोई सिफारिश है? जावा एक व्यवहार्य विकल्प है, और यदि आप कोई भी भाषा चुन सकते हैं, तो यह क्या होगा?

Answer 1

जीसी का उपयोग केवल त्याग किए गए ऑब्जेक्ट्स से स्मृति को पुनः प्राप्त करने के लिए किया जाता है। बहुत कम संसाधनों को छोड़ दें और आपको बहुत कम, कम जीसी मिलेंगे।

आप सॉकेट के बहुत सारे, फ़ाइल हैंडल, बाहरी libs से हैंडल का उपयोग कर सकते, लेकिन आप उन्हें कितनी तेजी से त्यागने करते हैं?

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

IMHO, मैं कम आप एक विलंबता अच्छी तरह से 10 एमएस, 99% समय की + किया जा रहा है, जिसके साथ एक नियंत्रण प्रणाली विकसित करने के लिए सक्षम होना चाहिए।

Answer 2

यदि आप जावा का उपयोग करना चाहते हैं तो शायद आपको अवधारणा साबित करने की आवश्यकता है, मैं कचरा संग्रह के दौरान उच्च भार के तहत आपके विलंबता समय की जांच करने के लिए एक सरल प्रोटोटाई और तनाव परीक्षण लिखने का सुझाव दूंगा। फिर विभिन्न कलेक्टर प्रकारों को चेकआउट करें i.g. low pause collector।

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

Answer 3

मैं (निश्चित रूप से किसी भी JVM मैंने देखा है में लागू के रूप में) जीसी से दूर रहने ऐसे वातावरण में होगा। आप हमेशा समस्या पर दीवार के खिलाफ अपने सिर को टक्कर लगी होगी।

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

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