स्पीडोमीटर, या कैसे क्रोमियम के साथ एक समस्या की कहानी स्मृति का प्रबंधन करती है

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

मेरा नाम एंड्री लोगविनोव है, मैं निज़नी नोवगोरोड में Yandex.Browser रेंडरिंग इंजन डेवलपमेंट ग्रुप में काम करता हूँ। आज मैं Habr के पाठकों को बताऊंगा कि क्रोमियम परियोजना में मेमोरी प्रबंधन एक रहस्यमय समस्या के उदाहरण से कैसे काम करता है जिसके कारण स्पीडोमीटर परीक्षण में प्रदर्शन में गिरावट आई। यह पोस्ट Yandex.Inside घटना से मेरी रिपोर्ट पर आधारित है।




एक बार हमारे प्रदर्शन डैशबोर्ड पर, हमने स्पीडोमीटर परीक्षण की गति में गिरावट देखी। यह परीक्षण ब्राउज़र के समग्र प्रदर्शन को मापता है, जो वास्तविकता के करीब है - एक टू-डू सूची, जहां परीक्षण आइटम को सूची में जोड़ता है और फिर उन्हें पार करता है। परीक्षण के परिणाम V8 JS इंजन के प्रदर्शन और पलक इंजन में पृष्ठों को रेंडर करने की गति दोनों से प्रभावित हैं। स्पीडोमीटर परीक्षण में कई उपप्रकार होते हैं, जहाँ परीक्षण अनुप्रयोग लोकप्रिय JS चौखटों में से एक का उपयोग करके लिखा जाता है, उदाहरण के लिए jQuery या ReactJS। समग्र परीक्षा परिणाम को सभी रूपरेखाओं के परिणामों के लिए औसत के रूप में परिभाषित किया गया है, लेकिन परीक्षण आपको प्रत्येक फ्रेमवर्क के प्रदर्शन को व्यक्तिगत रूप से देखने की अनुमति देता है। यह ध्यान देने योग्य है कि परीक्षण का उद्देश्य रूपरेखाओं के प्रदर्शन का मूल्यांकन करना नहीं है, उनका उपयोग केवल परीक्षण को कम सिंथेटिक और वास्तविक वेब अनुप्रयोगों के अधिक निकट बनाने के लिए किया जाता है। सबटैस्ट द्वारा पता लगाने से पता चला कि गिरावट केवल jQuery का उपयोग करके बनाए गए परीक्षण एप्लिकेशन के संस्करण के लिए देखी गई है। और यह पहले से ही दिलचस्प है, सहमत हैं।

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

चूँकि हमें किसी विशिष्ट परिवर्तन का संकेत देने वाली कोई सूचना नहीं मिली थी, इसलिए मुझे समस्या का गहन अध्ययन करना पड़ा। ऐसा करने के लिए, हमने परीक्षण के निशान हटाने के लिए डेवलपर टूल का उपयोग किया। हमने एक अजीब विशेषता देखी - जावास्क्रिप्ट-परीक्षण कार्यों के निष्पादन के लिए "फटा हुआ" अंतराल।



हम इसके बारे में अधिक तकनीकी ट्रेस निकालते हैं: ट्रेसिंग करते हैं और देखते हैं कि यह ब्लिंक में कचरा संग्रह (जीसी) है।



नीचे दिए गए मेमोरी ट्रैक से पता चलता है कि ये GC-pauses न केवल बहुत समय लेते हैं, बल्कि मेमोरी खपत के विकास को रोकने में भी मदद नहीं करते हैं।



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

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

हम स्टैक स्कैन के साथ कनेक्शन की जांच करते हैं और इसे छोड़ देते हैं। समस्या गायब हो गई है।

ऐसे ढेर में क्या हो सकता है जो 500 हजार वस्तुओं को रखता है? हम वस्तुओं को जोड़ने के कार्य में एक विराम बिंदु रखते हैं - अन्य बातों के अलावा, हम देखते हैं कि संदिग्ध है:

ब्लिंक :: ट्रेसट्रेट <ब्लिंक :: हैफशटेबलबैकिंग <डब्ल्यूटीएफ :: हैशटेबल <ब्लिंक :: वीकमेम्बर ...

एक हैश तालिका संदर्भ एक संभावित संदिग्ध है! हम इस लिंक को जोड़कर परिकल्पना का परीक्षण करते हैं। समस्या गायब हो गई है। खैर, हम उत्तर के करीब एक कदम हैं।

हम ब्लिंक में कचरा कलेक्टर की एक और विशेषता को याद करते हैं: यदि यह हैश टेबल के अंदर एक संकेतक देखता है, तो यह इसे टेबल पर चल रहे पुनरावृत्ति का संकेत मानता है, जिसका अर्थ है कि यह इस तालिका के सभी लिंक को उपयोगी मानता है और उन्हें बायपास करना जारी रखता है। हमारे मामले में, निष्क्रिय। लेकिन इस लिंक का स्रोत क्या है?

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

हमने मेमोरी सेल को बदलने पर एक ब्रेकपॉइंट सेट किया है, जिसमें हमें हैश टेबल का लिंक मिला है। हम देखते हैं कि V8PerIsolateData :: AddActiveScriptWrappable नामक एक आंतरिक फ़ंक्शन वहाँ लिखता है। वहां, वे इनपुट सहित कुछ प्रकार के एचटीएमएल तत्वों को जोड़ते हैं, जिसमें एक एकल हैश टेबल सक्रिय_सस्क्रिप्ट_रावैपबल्स_ शामिल है। इस तालिका को उन तत्वों को हटाने से रोकने की आवश्यकता है जो अब जावास्क्रिप्ट या डीओएम पेड़ से संदर्भित नहीं हैं, लेकिन जो किसी भी बाहरी गतिविधि से जुड़े हैं, उदाहरण के लिए, घटनाओं को उत्पन्न कर सकते हैं।

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

लेकिन एक फ़ंक्शन के स्टैक से दूसरे के स्टैक को कैसे मारा गया?!

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

0FCDD13A push ebp 0FCDD13B mov ebp,esp 0FCDD13D push edi 0FCDD13E push esi 0FCDD13F and esp,0FFFFFFF8h 0FCDD142 sub esp,0B8h 0FCDD148 mov eax,dword ptr [__security_cookie (13DD3888h)] 0FCDD14D mov esi,ecx 0FCDD14F xor eax,ebp 0FCDD151 mov dword ptr [esp+0B4h],eax 

यह देखा जा सकता है कि फ़ंक्शन 0B8h पर जासूसी करता है , और इस स्थान का उपयोग आगे नहीं किया जाता है। लेकिन इस वजह से, स्टैक स्कैनर देखता है कि अन्य कार्यों द्वारा पहले क्या रिकॉर्ड किया गया था। और संयोग से, AddActiveScriptWrappable फ़ंक्शन द्वारा छोड़ी गई हैश तालिका के अंदर एक सूचक इस "छेद" में जाता है। जैसा कि यह निकला, इस मामले में "छेद" के प्रकट होने का कारण फ़ंक्शन के अंदर वीएलओजी डीबग मैक्रो था, जो लॉग में अतिरिक्त जानकारी प्रदर्शित करता है।

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

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

दिलचस्प लिंक

1. यदि आप हमारे समूह के अन्य असामान्य रोजमर्रा के जीवन के बारे में जानने में रुचि रखते हैं, तो हम काले आयत की कहानी को याद करते हैं, जिसके कारण न केवल यैंडेक्स.ब्रोसर, बल्कि पूरे क्रोमियम प्रोजेक्ट का त्वरण हुआ।

2. और मैं आपको अगले यैंडेक्स में अन्य रिपोर्टों को सुनने के लिए भी आमंत्रित करता हूं। 16 फरवरी को उल्टा घटना, पंजीकरण खुला है, और प्रसारण भी होगा।