क्या निर्धारक कचरा संग्रह एल्गोरिदम बाहर हैं?

Question

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

मैं भी प्रश्न में शामिल कर रहा हूँ किसी भी कचरा संग्रहण एल्गोरिदम कि वे किस तरह इस्तेमाल कर रहे हैं पर प्रतिबंध लगा।

Answer 1

मैं जानता हूँ कि Azul प्रणालियों एक JVM जिसका जीसी हार्डवेयर सहायता प्रदान की है है। यह समवर्ती रूप से भी चला सकता है और भारी मात्रा में डेटा एकत्रित कर सकता है।

लेकर सुनिश्चित नहीं हैं नियतात्मक यह हालांकि है।

Answer 2

Metronome GC और BEA JRockit दो निर्धारक जीसी कार्यान्वयन हैं जिन्हें मैं (जावा के लिए दोनों) से अवगत हूं।

Answer 3

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

मैं इन लेखों पर पढ़ने की सलाह देते हैं - Cliff Click blog। वह अज़ुल के वास्तुकार हैं, ने सभी मानक 1.5 जावा समवर्ती वर्गों आदि को बहुत अधिक कोड किया है ... एफवाईआई, अज़ुल उन प्रणालियों के लिए डिज़ाइन किया गया है जिनके लिए मानक आरटी आवश्यकताओं की बजाय बहुत बड़े ढेर आकार की आवश्यकता होती है।

Answer 4

आपको निम्नलिखित पीएचडी थीसिस CMU-CS-01-174 - Scalable Real-time Parallel Garbage Collection for Symmetric Multiprocessors के साथ कुछ भाग्य हो सकता है।

Answer 5

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

एक महत्वपूर्ण रीयलटाइम सिस्टम में, आप सिस्टम मानक मॉलोक()/फ्री() को एक अलग कार्यान्वयन के साथ भी बदल सकते हैं, शायद अपना खुद का एक लिखना भी (यह उतना कठिन नहीं है जितना लगता है! मैंने इसे पहले किया है बस इसके मजाक के लिए) जो सबसे निर्णायक काम करता है। मेरे लिए जीसी एक सादा सुविधा है, यह प्रोग्रामर को परिष्कृत मॉलोक()/फ्री() योजना पर ध्यान केंद्रित करने से दूर करने और सिस्टम को स्वचालित रूप से इसके साथ सौदा करने के लिए प्राप्त करना है। यह तेजी से सॉफ्टवेयर विकास करने में मदद करता है और मेमोरी लीक को ठीक करने और फिक्सिंग के डिबगिंग के घंटों बचाता है। लेकिन जैसे कि मैं कभी भी एक ऑपरेटिंग सिस्टम कर्नेल के भीतर जीसी का उपयोग नहीं करता था, मैं इसे कभी भी एक महत्वपूर्ण रीयलटाइम एप्लिकेशन के भीतर उपयोग नहीं करता।

यदि मुझे एक अधिक परिष्कृत स्मृति प्रबंधन की आवश्यकता है, तो मैं शायद अपना खुद का मॉलोक()/फ्री() लिखूंगा जो वांछित (और सबसे निर्धारिती) के रूप में काम करता है और इसके ऊपर अपना स्वयं का संदर्भ गिनती मॉडल लिखता है। संदर्भ गिनती अभी भी मैन्युअल मेमोरी प्रबंधन है, लेकिन केवल malloc()/free() का उपयोग करने से कहीं अधिक आरामदायक है। यह अल्ट्रा फास्ट नहीं है, लेकिन निर्धारिती (कम से कम रेफ काउंटर को बढ़ाने/घटाने में गति में निर्धारक है) और जब तक आपके पास परिपत्र संदर्भ नहीं हो सकते हैं, तो यदि आप अपने आवेदन में एक सतत/रिलीज रणनीति का पालन करते हैं तो यह सभी मृत स्मृति को पकड़ लेगा।इसके बारे में एकमात्र गैर निर्धारिती हिस्सा यह है कि आपको पता नहीं चलेगा कि कॉलिंग रिलीज केवल रेफ काउंटर को कम करेगा या वास्तव में ऑब्जेक्ट को मुक्त करेगा (निर्भर करता है कि रेफ गिनती शून्य हो या नहीं), लेकिन आप वास्तविक पेशकश में देरी कर सकते हैं "रिलीज के बिना फ्रिइंग" कहने के लिए फ़ंक्शन, जो एक द्वारा रेफ काउंटर को कम करता है, लेकिन यदि यह शून्य तक पहुंच जाता है, तो यह ऑब्जेक्ट को अभी भी मुक्त नहीं करेगा()। आपके मॉलोक()/फ्री() कार्यान्वयन में एक फ़ंक्शन "findDeadObjects" हो सकता है जो शून्य के रखरखाव काउंटर के साथ सभी ऑब्जेक्ट्स की खोज करता है, जिन्हें अभी तक जारी नहीं किया गया है और उन्हें मुक्त किया गया है (बाद में, जब आप कम महत्वपूर्ण होते हैं आपके कोड का हिस्सा जिसमें इस तरह के कार्यों के लिए अधिक समय है)। चूंकि यह भी निर्धारिती नहीं है, इसलिए आप "findDeadObjectsForUpTo (ms)" जैसे समय के लिए उपयोग कर सकते हैं, और एमएस मिलीसेकंड की मात्रा है जो इसे खोजने और मुक्त करने के लिए उपयोग कर सकती है, इस बार जल्द ही वापस आ रही है क्वांटम का उपयोग किया गया है, इसलिए आप इस कार्य में ज्यादा समय नहीं बिताएंगे।

Answer 6

यह जीसी नहीं है, लेकिन सरल ओ (1) निश्चित आकार ब्लॉक आवंटन/मुक्त योजनाएं हैं जिनका उपयोग आप सरल उपयोग के लिए कर सकते हैं। उदाहरण के लिए, आप निश्चित आकार के ब्लॉक की एक मुफ्त सूची का उपयोग कर सकते हैं।

struct Block { 
    Block *next; 
} 

Block *free_list = NULL; /* you will need to populate this at start, an 
          * easy way is to just call free on each block you 
          * want to add */ 

void release(void *p) { 
    if(p != NULL) { 
     struct Block *b_ptr = (struct Block *)p; 
     b_ptr->next = free_list; 
     free_list = b_ptr; 
    } 
} 

void *acquire() { 
    void *ret = (void *)free_list; 
    if(free_list != NULL) { 
     free_list = free_list->next; 
    } 
    return ret; 
} 

/* call this before you use acquire/free */ 
void init() { 
    /* example of an allocator supporting 100 blocks each 32-bytes big */ 
    static const int blocks = 100; 
    static const int size = 32; 
    static unsigned char mem[blocks * size]; 
    int i; 
    for(i = 0; i < blocks; ++i) { 
     free(&mem[i * size]); 
    } 
} 

आप तदनुसार योजना है, आप गतिशील आवंटन के लिए केवल कुछ विशिष्ट आकार के लिए अपने डिजाइन को सीमित करने और प्रत्येक संभावित आकार के लिए एक free_list हो सकता था। आप ग उपयोग कर रहे हैं ++, आप कुछ scoped_ptr की तरह साधारण लागू कर सकते हैं (प्रत्येक आकार के लिए, मैं एक टेम्पलेट परम का उपयोग करेंगे) सरल अभी तक अभी भी हे (1) स्मृति प्रबंधन के लिए।

केवल वास्तविक चेतावनी है, कि तुम होगा डबल मुक्त करता है या यहाँ तक कि गलती से जो अधिग्रहण से नहीं आया था जारी करने के लिए एक ptr गुजर से कोई सुरक्षा है।

Answer 7

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

वहाँ सुविधाओं, RT-जावा में क्षेत्रों, कि स्थानीय और वैश्विक (स्थिर) चर परे अभिव्यक्ति के लिए अनुमति की तरह हैं। लेकिन वे आपके द्वारा आवंटित स्मृति को प्रबंधित करने के लिए आपको अपनी ज़िम्मेदारी से राहत नहीं देंगे, अन्यथा आप गारंटी नहीं दे सकते कि अगली आगामी आवंटन अपर्याप्त स्मृति संसाधनों के कारण विफल नहीं होगी।

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

// assume that on `Link` object needs k bytes: 
class Link { 
    Link next = null; 
    /* further fields */ 
    static Link head = null; 
} 

public static void main (String args) { 
    // assume we have N bytes free now 
    // set n := floor (N/k), assume that n > 1 

    for (int i = 0; i < n; i ++) { 
     Link tmp = new Link(); 
     tmp.next = Link.head; 
     Link.head = tmp; 
    } 
    // (1) 
    Link.head = Link.head.next; // (2) 
    Link tmp = new Link(); // (3) 
} 

• बिंदु पर (1), हम से k बाइट्स मुक्त (एक और के आवंटन कम है Link ऑब्जेक्ट असफल हो जाएगा), और सभी Link अब तक आवंटित ऑब्जेक्ट्स Link.static Link head फ़ील्ड से पहुंचने योग्य पहुंच योग्य हैं।
• बिंदु (2) पर

  ,

  • (क) क्या होना करने के लिए सूची में पहले प्रवेश अब पहुंच योग्य नहीं है, लेकिन
  • (ख) यह अभी भी आवंटित किया जाता है, जहाँ तक स्मृति प्रबंधन भाग चिंतित है।

• बिंदु (3), आवंटन क्योंकि (2 ए) के सफल होने चाहिए पर -, की वजह से (2 बी), हम शुरू करनी चाहिए लेकिन - हम उपयोग कर सकते हैं क्या पहले लिंक हुआ करता था जीसी, जो ट्रैवलिंग एन -1 ऑब्जेक्ट्स को समाप्त कर देगा, इसलिए ओ (एन) के चल रहे समय हैं।

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

Answer 8

सूर्य ने अपने वास्तविक समय कचरा कलेक्टर को बड़े पैमाने पर दस्तावेज किया है, और बेंचमार्क प्रदान किए हैं जो आप अपने लिए चला सकते हैं here। अन्य ने मेट्रोनोम का उल्लेख किया, जो अन्य प्रमुख उत्पादन-ग्रेड आरटीजीसी एल्गोरिदम है। आरटी जेवीएम के कई अन्य विक्रेताओं के पास अपने स्वयं के कार्यान्वयन हैं - विक्रेताओं की मेरी सूची देखें over here और उनमें से अधिकतर व्यापक दस्तावेज प्रदान करते हैं।

यदि आपकी रुचि विशेष रूप से एवियनिक्स/फ्लाइट सॉफ़्टवेयर में है, तो मेरा सुझाव है कि आप aicas देखें, एक आरटीएसजे विक्रेता जो विशेष रूप से एवियनिक्स उद्योग को बाजार देता है। Dr. Siebert (एआईसीए सीईओ) होम पेज कुछ अकादमिक प्रकाशनों को सूचीबद्ध करता है जो PERC के जीसी कार्यान्वयन के बारे में बहुत विस्तृत जानकारी देते हैं।

Answer 9

स्टैक ओवरफ़्लो के माध्यम से खोज करने के लिए हुआ और इस पुरानी पोस्ट को देखा।

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

मैं जमैकावीएम, जमैकाकार और वेरिफ्लक्स के एकास, डेवलपर्स और मार्केटर्स के लिए काम करता हूं।

जमैकाVM में हार्ड रीयलटाइम कचरा कलेक्टर है। यह पूरी तरह से preemptive है। रीयलटाइम ऑपरेटिंग सिस्टम में सटीक समान व्यवहार आवश्यक है। हालांकि प्रीपेशन विलंबता सीपीयू गति निर्भर है, मान लीजिए कि कचरा कलेक्टर की एक गीज़ क्लास प्रोसेसर की छूट 1 माइक्रोसॉन्ड से कम है। एक 32 बिट सिंगलकोर संस्करण है जो प्रति प्रक्रिया पता स्थान के 3 जीबी मेमोरी का समर्थन करता है। एक 32 बिट मल्टीकोर संस्करण है जो 3 जीबी मेमोरी प्रति प्रोसेस एड्रेस स्पेस और एकाधिक कोर का समर्थन करता है। 64 बिट सिंगलकोर और मल्टीकोर संस्करण भी हैं जो 128 जीबी मेमोरी प्रति प्रोसेस एड्रेस स्पेस का समर्थन करते हैं। कचरा कलेक्टर का प्रदर्शन स्मृति के आकार से स्वतंत्र है। जीसी को पूरी तरह स्मृति से बाहर करने के संबंध में प्रतिक्रियाओं में से एक के जवाब में, हार्ड रीयलटाइम सिस्टम के लिए आप अपने प्रोग्राम को कभी भी ऐसा करने के लिए डिज़ाइन नहीं करेंगे। यद्यपि आप वास्तव में, इस परिदृश्य में एक हार्ड रीयलटाइम जीसी का उपयोग कर सकते हैं, आपको सबसे खराब केस निष्पादन समय के लिए जिम्मेदार होना होगा जो शायद आपके आवेदन के लिए स्वीकार्य नहीं होगा।

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

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

ऐसा नहीं है कि वास्तविक समय कचरा संग्रहण को समझने के लिए बहुत महत्वपूर्ण है कई चीजें का मतलब है:

1. कचरा कलेक्टर, किसी भी अन्य ऑपरेटिंग सिस्टम सेवा
2. यह साबित किया जा सकता है, जैसे preemptible है गणितीय कि कचरा कलेक्टर जारी रहेगा, इस तरह की स्मृति समाप्त नहीं होगी क्योंकि कुछ स्मृति अभी तक पुनः दावा नहीं की गई है।
3. कचरा कलेक्टर स्मृति को खंडित नहीं करता है, जैसे कि स्मृति उपलब्ध होने तक, एक स्मृति अनुरोध सफल होगा।
4. इसके अतिरिक्त, आपको प्राथमिकता उलटा सुरक्षा, एक निश्चित प्राथमिकता थ्रेड शेड्यूलर और अन्य सुविधाओं वाले सिस्टम का हिस्सा बनने की आवश्यकता होगी। इस पर कुछ जानकारी के लिए आरटीएसजे का संदर्भ लें।

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

Answer 10

मुझे पता है कि यह पोस्ट थोड़ा दिनांकित है, लेकिन मैंने कुछ दिलचस्प शोध किया है और यह सुनिश्चित करना चाहते हैं कि यह अपडेट हो।

एज़ुल सिस्टम्स "ज़िंग जेवीएम" और जेआरकेट द्वारा निर्धारित जीसी की पेशकश की जा सकती है। ज़िंग कुछ बहुत ही रोचक विशेषताओं के साथ आता है और अब "100% सॉफ्टवेयर आधारित" है (x86 मशीनों पर चलाया जा सकता है)। यही वह समय है, हालांकि पर केवल लिनक्स के लिए है ...

कीमत: आप जावा 6 या उससे पहले ओरेकल अब एक 300% उत्थान चार्ज और इस क्षमता (प्रोसेसर प्रति $ 15,000 & $ 3,300 समर्थन) के लिए समर्थन मजबूर कर रहा है कर रहे हैं। अज़ुल, जो मैंने सुना है, वह करीब 10,000 डॉलर है - $ 12,000, लेकिन भौतिक मशीन द्वारा शुल्क, कोर/प्रोसेसर नहीं। इसके अलावा, प्रक्रिया वॉल्यूम द्वारा स्नातक की जाती है ताकि अधिक सर्वर आप छूट को गहराई से लाभ उठा सकें। उनके साथ मेरी बातचीत ने उन्हें काफी लचीला दिखाया। ओरेकल एक सतत लाइसेंस है और ज़िंग सदस्यता आधारित है ... लेकिन यदि आप गणित करते हैं और ज़िंग के अन्य विशेषताओं में जोड़ते हैं (नीचे मतभेद देखें)।

आप जावा 7 पर जाकर लागत में कटौती कर सकते हैं, लेकिन फिर विकास लागत लगाना। ओरेकल के रोडमैप (प्रत्येक 18 महीने या उससे भी अधिक की एक नई रिलीज) को देखते हुए, और तथ्य यह है कि वे ऐतिहासिक रूप से केवल जावा एसई अपडेट के नवीनतम प्लस वन संस्करणों को मुफ्त में पेश करते हैं, "फ्री" क्षितिज प्रारंभिक GA से 3 साल होने की उम्मीद है अगर कोई बड़ा संस्करण जारी करें। चूंकि शुरुआती जीए रिलीज आमतौर पर 12-18 महीने के लिए उत्पादन में अपनाया नहीं जाता है, और नए प्रमुख जावा रिलीज में चलती उत्पादन प्रणालियों में आम तौर पर बड़ी लागत होती है, इसका मतलब है कि जावा एसई समर्थन बिल शुरुआती तैनाती के बाद 6 से 24 महीने के बीच कहीं भी मारना शुरू कर देंगे ।

उल्लेखनीय मतभेद: रैम के मामले में जेरोकेट में अभी भी कुछ स्केलेबिलिटी सीमाएं हैं (हालांकि पुराने दिनों से बेहतर)। आप अपने परिणामों को थोड़ा ट्यूनिंग के साथ बेहतर बना सकते हैं। ज़िंग ने निरंतर, समवर्ती, कॉम्पैक्शन की अनुमति देने के लिए अपने एल्गोरिदम को इंजीनियर किया है (दुनिया को रोक नहीं है और कोई "ट्यूनिंग" आवश्यक नहीं है)। यह ज़िंग को सैद्धांतिक स्मृति छत के बिना स्केल करने की अनुमति देता है (वे दुनिया को रोकने या क्रैश होने के बिना 300+ जीबी ढेर कर रहे हैं)। एक प्रतिमान परिवर्तक के बारे में बात करें (बड़े डेटा के प्रभाव के बारे में सोचें)।ज़िंग में कुछ काम के साथ अद्भुत प्रदर्शन देने के लिए लॉक करने के लिए कुछ वाकई अच्छे सुधार हैं (यदि ट्यून किया गया है, तो उप-मिलीसेकंड औसत जा सकता है)। अंत में, उनके पास उत्पादन में कक्षाओं, विधियों और धागे के व्यवहार में दृश्यता नहीं है (कोई ओवरहेड नहीं)। अद्यतन, पैच, और बग फिक्स (उदाहरण के लिए लीक & ताले) पर विचार करते समय हम इसे एक विशाल समय बचतकर्ता के रूप में देखते हैं। यह देव/टेस्ट में कई मुद्दों को फिर से बनाने की जरूरत को खत्म कर सकता है। JVM डाटा को

लिंक मैंने पाया:

JRocket Deterministic GC

Azul Presentation - Java without Jitter

Azul/MyChannels Test