X64 पर C ++ एक्सेप्शन हैंडलिंग को छोटा बनाना

विजुअल स्टूडियो 2019 प्रीव्यू 3 x64 पर C ++ अपवाद हैंडलिंग (कोशिश / पकड़ और स्वचालित विध्वंसक) के द्विआधारी आकार को कम करने के लिए एक नई सुविधा का परिचय देता है। डब्ड FH4 (__CxxFrameHandler4 के लिए, नीचे देखें), मैंने C ++ अपवाद हैंडलिंग के लिए उपयोग किए गए डेटा के लिए नया स्वरूपण और प्रसंस्करण विकसित किया है, जो मौजूदा कार्यान्वयन की तुलना में ~ 60% छोटा है, जिसके परिणामस्वरूप C ++ के भारी उपयोग वाले कार्यक्रमों के लिए 20% तक समग्र द्विआधारी कमी आई है। अपवाद से निपटने।

मैं इसे कैसे चालू करूं?

FH4 वर्तमान में डिफ़ॉल्ट रूप से बंद है क्योंकि स्टोर एप्लिकेशन के लिए आवश्यक रनटाइम परिवर्तन इसे वर्तमान रिलीज़ में नहीं बना सका। गैर-स्टोर अनुप्रयोगों के लिए FH4 को चालू करने के लिए, Visual Studio 2019 पूर्वावलोकन 3 और उसके बाद के MSVC कंपाइलर में अनिर्धारित ध्वज "/ d2FH4" पास करें।

स्टोर रनटाइम अपडेट होने के बाद हम डिफ़ॉल्ट रूप से FH4 को सक्षम करने की योजना बनाते हैं। हम विजुअल स्टूडियो 2019 अपडेट 1 में ऐसा करने की उम्मीद कर रहे हैं और इस पोस्ट को अपडेट करेंगे जिसे हम अधिक जानते हैं।

उपकरण बदल जाता है

विजुअल स्टूडियो 2019 प्रीव्यू 3 और उसके बाद के किसी भी इंस्टॉलेशन में FH4 को सपोर्ट करने के लिए कंपाइलर और C ++ रनटाइम में बदलाव होंगे। संकलक परिवर्तन आंतरिक रूप से उपरोक्त "/ d2FH4" झंडे के नीचे मौजूद हैं। C ++ रनटाइम स्पोर्ट्स vcruntime140_1.dll नामक एक नए DLL को स्वचालित रूप से VCRedist द्वारा स्थापित किया गया है। नए अपवाद हैंडलर __CxxFrameHandler4 को पुराने __CxxFrameHandler3 रूटीन को बदलने की आवश्यकता है। नए C ++ रनटाइम के स्टेटिक लिंकिंग और ऐप-लोकल परिनियोजन, दोनों का समर्थन किया जाता है।

अब मज़े की चीज़ पर! इस पोस्ट के बाकी हिस्सों में विंडोज, ऑफिस और एसक्यूएल पर एफएच 4 का परीक्षण करने से आंतरिक परिणाम शामिल होंगे, इसके बाद इस नई तकनीक के पीछे अधिक गहराई से तकनीकी विवरण होंगे।

प्रेरणा और परिणाम

लगभग एक साल पहले, C ++ / WinR T प्रोजेक्ट पर हमारे साथी Microsoft C ++ टीम के लिए एक चुनौती लेकर आए थे: हम उन कार्यक्रमों के लिए बाइनरी साइज़ हैंडलिंग C ++ के अपवाद को कितना कम कर सकते थे जो इसका भारी उपयोग करते थे?

C ++ / WinRT का उपयोग करते हुए एक कार्यक्रम के संदर्भ में, उन्होंने हमें एक Windows घटक Microsoft.UI.Xaml.dll की ओर इशारा किया जिसे C ++ अपवाद हैंडलिंग के कारण एक बड़े बाइनरी फ़ुटप्रिंट के लिए जाना जाता था। मैंने पुष्टि की कि यह वास्तव में मामला था और नीचे दिखाए गए मौजूदा __CxxFrameHandler3 के साथ द्विआधारी आकार के टूटने को उत्पन्न करता है। चार्ट के दाहिने हिस्से में प्रतिशत कुल बाइनरी आकार का प्रतिशत है जो विशिष्ट मेटाडेटा तालिकाओं और उल्लिखित कोड द्वारा कब्जा कर लिया गया है।

मैं इस पोस्ट में चर्चा नहीं करूंगा कि चार्ट के दाईं ओर की विशिष्ट संरचनाएं क्या करती हैं (देखें जेम्स मैकनेलिस की चर्चा अधिक जानकारी के लिए विंडोज पर स्टैक अनइंडिंग कैसे काम करती है )। हालांकि कुल मेटाडेटा और कोड को देखते हुए, बाइनरी आकार का 26.4% सी ++ अपवाद हैंडलिंग द्वारा उपयोग किया गया था। यह एक विशाल स्थान है और C ++ / WinRT को अपनाने में बाधा उत्पन्न कर रहा था।

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

नए __CxxFrameHandler4 और उसके साथ मेटाडेटा के साथ, Microsoft.UI.XAML.dll के लिए आकार का टूटना अब निम्नलिखित है:

सी + + अपवाद हैंडलिंग द्वारा उपयोग किए जाने वाले बाइनरी आकार 64% तक गिरता है जिससे इस बाइनरी पर 18.6% की कुल द्विआधारी आकार की कमी होती है। हर प्रकार की संरचना कंपित डिग्री द्वारा आकार में सिकुड़ गई:

संयुक्त, __CxxFrameHandler4 पर स्विचिंग ने Microsoft.UI.Xaml.dll का समग्र आकार 4.4 एमबी से 3.6 एमबी नीचे गिरा दिया।

Office बायनेरिज़ के प्रतिनिधि सेट पर FH4 का परीक्षण करने से DLL में ~ 10% आकार में कमी दिखाई देती है जो अपवादों का भारी उपयोग करते हैं। यहां तक ​​कि वर्ड और एक्सेल में, जो अपवाद उपयोग को कम करने के लिए डिज़ाइन किए गए हैं, अभी भी द्विआधारी आकार में एक सार्थक कमी है।

मुख्य SQL बायनेरी पर FH4 का परीक्षण करने से आकार में 4-21% की कमी दिखाई देती है, मुख्य रूप से अगले भाग में वर्णित मेटाडेटा संपीड़न से:

तकनीक

जब Microsoft +UI.Xaml.dll में डेटा को संभालने के लिए C ++ अपवाद से निपटने के कारण क्या हुआ, इसका विश्लेषण करते हुए मैंने दो प्राथमिक गुण पाए:

1. डेटा संरचनाएं स्वयं बड़ी हैं: मेटाडेटा तालिकाएँ प्रत्येक चार बाइट्स लंबी छवि-सापेक्ष ऑफ़सेट्स और पूर्णांकों के क्षेत्रों के साथ निश्चित आकार की थीं। एकल प्रयास / कैच और एक या दो स्वचालित विध्वंसक के साथ एक फ़ंक्शन में मेटाडेटा के 100 से अधिक बाइट्स थे।
2. डेटा संरचना और उत्पन्न कोड विलय के लिए उत्तरदायी नहीं थे। मेटाडेटा तालिकाओं में इमेज-रिलेटेड ऑफ़सेट्स होते हैं जो COMDAT फोल्डिंग को रोकते हैं (प्रक्रिया जहां लिंकर स्पेस को बचाने के लिए डेटा के समान टुकड़ों को एक साथ जोड़ सकते हैं) जब तक कि वे जो फ़ंक्शन का प्रतिनिधित्व करते हैं वे समान नहीं थे। इसके अलावा, कैच फंट्ट्स (प्रोग्राम के कैच ब्लॉक्स से उल्लिखित कोड) को तब भी फोल्ड नहीं किया जा सकता है, यदि वे कोड-समान थे, क्योंकि उनका मेटाडेटा उनके माता-पिता में समाहित है।

इन मुद्दों को हल करने के लिए, FH4 मेटाडेटा और कोड को इस तरह से पुनर्गठन करता है:

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

इसे समझने के लिए, आइए __CxxFrameHandler3 के लिए उपयोग किए जाने वाले फ़ंक्शन जानकारी मेटाडेटा तालिका की मूल परिभाषा देखें। यह रनटाइम के लिए प्रारंभिक तालिका है जब प्रसंस्करण ईएच और अन्य मेटाडेटा तालिकाओं को इंगित करता है। यह कोड सार्वजनिक रूप से किसी भी वीएस इंस्टॉलेशन में उपलब्ध है, <VS इंस्टॉल पथ> \ VC \ Tools \ MSVC \ <वर्जन> \ _ \ ehdata.h देखें:

typedef const struct _s_FuncInfo { unsigned int magicNumber:29; // Identifies version of compiler unsigned int bbtFlags:3; // flags that may be set by BBT processing __ehstate_t maxState; // Highest state number plus one (thus // number of entries in unwind map) int dispUnwindMap; // Image relative offset of the unwind map unsigned int nTryBlocks; // Number of 'try' blocks in this function int dispTryBlockMap; // Image relative offset of the handler map unsigned int nIPMapEntries; // # entries in the IP-to-state map. NYI (reserved) int dispIPtoStateMap; // Image relative offset of the IP to state map int dispUwindHelp; // Displacement of unwind helpers from base int dispESTypeList; // Image relative list of types for exception specifications int EHFlags; // Flags for some features. } FuncInfo; 

यह संरचना प्रत्येक 4 बाइट्स वाले 10 फ़ील्ड वाले निश्चित आकार की है। इसका मतलब यह है कि हर फ़ंक्शन को मेटाडेटा के 40 बाइट्स को डिफ़ॉल्ट रूप से C ++ अपवाद हैंडलिंग की आवश्यकता होती है।

अब नई डेटा संरचना में (<VS इंस्टॉल पथ> \ VC \ Tools \ MSVC \ <संस्करण> \ शामिल \ ehdata4_export.h):

 struct FuncInfoHeader { union { struct { uint8_t isCatch : 1; // 1 if this represents a catch funclet, 0 otherwise uint8_t isSeparated : 1; // 1 if this function has separated code segments, 0 otherwise uint8_t BBT : 1; // Flags set by Basic Block Transformations uint8_t UnwindMap : 1; // Existence of Unwind Map RVA uint8_t TryBlockMap : 1; // Existence of Try Block Map RVA uint8_t EHs : 1; // EHs flag set uint8_t NoExcept : 1; // NoExcept flag set uint8_t reserved : 1; }; uint8_t value; }; }; struct FuncInfo4 { FuncInfoHeader header; uint32_t bbtFlags; // flags that may be set by BBT processing int32_t dispUnwindMap; // Image relative offset of the unwind map int32_t dispTryBlockMap; // Image relative offset of the handler map int32_t dispIPtoStateMap; // Image relative offset of the IP to state map uint32_t dispFrame; // displacement of address of function frame wrt establisher frame, only used for catch funclets }; 

ध्यान दें कि:

1. मैजिक नंबर हटा दिया गया है, हर बार 0x19930522 का उत्सर्जन एक समस्या बन जाता है जब एक प्रोग्राम में इन प्रविष्टियों में से हजारों होते हैं।
2. EHFlags को हेडर में ले जाया गया है जबकि C ++ 17 में डायनेमिक अपवाद विनिर्देशों के गिराए गए समर्थन के कारण डिस्पैस्ट लिस्ट को चरणबद्ध रूप से हटा दिया गया है। कंपाइलर पुराने __CxxFrameHandler3 को डिफ़ॉल्ट करेगा यदि डायनेमिक अपवाद विनिर्देशों का उपयोग किया जाता है।
3. अन्य तालिकाओं की लंबाई अब "फ़ंक्शन जानकारी 4" में संग्रहीत नहीं की जाती है। यह COMDAT फोल्डिंग को पॉइंट-टेबल के अधिक मोड़ने की अनुमति देता है, भले ही "फंक्शन इन्फो 4" टेबल को ही फोल्ड नहीं किया जा सके।
4. (स्पष्ट रूप से नहीं दिखाया गया है) dispFrame और bbtFlags फ़ील्ड अब चर-लंबाई पूर्णांक हैं। उच्च-स्तरीय प्रतिनिधित्व इसे आसान प्रसंस्करण के लिए uint32_t के रूप में छोड़ देता है।
5. bbtFlags, dispUnwindMap, dispTryBlockMap, और dispFrame को हेडर में सेट किए गए फ़ील्ड के आधार पर छोड़ा जा सकता है।

इस सब को ध्यान में रखते हुए, नई "फंक्शन इन्फो 4" संरचना का औसत आकार अब 13 बाइट्स (1 बाइट हैडर + तीन 4 बाइट इमेज अन्य कार्यालयों के सापेक्ष बाइट्स) है जो कुछ तालिकाओं की आवश्यकता नहीं होने पर भी आगे बढ़ सकता है। तालिकाओं की लंबाई को हटा दिया गया था, लेकिन ये मान अब संपीड़ित हैं और उनमें से 90% Microsoft.UI.Xaml.dll में एक ही बाइट के भीतर फिट पाए गए। सभी को एक साथ रखते हुए, इसका मतलब है कि नए हैंडलर में समान कार्यात्मक डेटा का प्रतिनिधित्व करने के लिए औसत आकार पिछले 40 बाइट्स की तुलना में 16 बाइट्स है - काफी नाटकीय सुधार!

तह करने के लिए, आइए पुराने और नए हैंडलर के साथ अद्वितीय तालिकाओं और फन्नों की संख्या देखें:

RVA को हटाकर अतिरिक्त तह के अवसर पैदा करने और पकड़ने वाले फन्नों को फिर से डिज़ाइन करने से अद्वितीय EH डेटा प्रविष्टियों की संख्या 48% तक गिर जाती है। मैं विशेष रूप से हरे रंग में इटैलिकाइज़्ड कैच फंकट्स की संख्या को कॉल करना चाहता हूं: यह 2.603 से घटकर केवल 84 हो जाता है। यह C ++ / WinRT का परिणाम है HRESULTs को C ++ अपवादों में तब्दील करना, जो कोड-समान कैच फ़ंक्शंस के बहुत सारे हैं जो अब हो सकते हैं बंद हो गई। निश्चित रूप से इस परिमाण की एक बूंद परिणामों के उच्च-अंत पर है, लेकिन फिर भी यह दर्शाता है कि संभावित आकार की बचत तह प्राप्त कर सकती है जब डेटा संरचनाओं को इसके साथ डिजाइन किया जाता है।

प्रदर्शन

डिजाइन को कम्प्रेशन शुरू करने और रनटाइम निष्पादन को संशोधित करने के साथ अपवाद संचालन प्रदर्शन के प्रभावित होने की चिंता थी। हालांकि, प्रभाव एक सकारात्मक है: अपवाद हैंडलिंग प्रदर्शन __CxxFrameHandler4 के साथ __CxxFrameHandler3 के विपरीत बेहतर होता है । मैंने एक बेंचमार्क प्रोग्राम का उपयोग करके थ्रूपुट का परीक्षण किया जो कि प्रत्येक 100 स्टैक फ्रेम के माध्यम से एक कोशिश / पकड़ और 3 स्वचालित वस्तुओं को नष्ट करने के लिए तैयार करता है। यह प्रोफ़ाइल निष्पादन समय के लिए 50,000 बार चलाया गया था, जिसके समग्र निष्पादन समय के लिए अग्रणी:

प्रोफाइलिंग से पता चला है कि अपघटन अतिरिक्त प्रसंस्करण समय का परिचय देता है, लेकिन इसकी लागत नई दुकानों के डिजाइन में थ्रेड-लोकल स्टोरेज के लिए कम स्टोरों से अधिक है।

भविष्य की योजना

जैसा कि शीर्षक में बताया गया है, FH4 वर्तमान में केवल x64 बायनेरिज़ के लिए सक्षम है। हालाँकि, वर्णित तकनीकें ARM32 / ARM64 के लिए एक्स्टेंसिबल हैं और कुछ हद तक x86 हैं। हम वर्तमान में इस तकनीक को अन्य प्लेटफार्मों पर विस्तारित करने के लिए प्रेरित करने के लिए (जैसे Microsoft.UI.Xaml.dll) अच्छे उदाहरणों की तलाश कर रहे हैं - यदि आपको लगता है कि आपके पास एक अच्छा उपयोग मामला है तो हमें बताएं!

एफएच 4 का समर्थन करने के लिए स्टोर एप्लिकेशन के रनटाइम परिवर्तन को एकीकृत करने की प्रक्रिया उड़ान में है। एक बार ऐसा करने के बाद, नया हैंडलर डिफ़ॉल्ट रूप से सक्षम हो जाएगा, ताकि हर कोई बिना किसी अतिरिक्त प्रयास के इन बाइनरी आकार की बचत प्राप्त कर सके।

समापन टिप्पणी

जो कोई भी सोचता है कि उनके x64 बायनेरिज़ कुछ ट्रिमिंग के साथ कर सकते हैं: आज FH4 ('/ d2FH4' के माध्यम से) आज़माएं! हम यह देखने के लिए उत्साहित हैं कि यह अब कौन सी बचत प्रदान कर सकता है कि यह सुविधा जंगल में है। बेशक, यदि आप किसी भी मुद्दे का सामना करते हैं, तो कृपया नीचे दिए गए टिप्पणियों में हमें ई-मेल ( visualcpp@microsoft.com ), या डेवलपर समुदाय के माध्यम से बताएं । आप हमें ट्विटर ( @VisualC ) पर भी देख सकते हैं।

Kenny Kerr को Microsoft.UI.Xaml.dll पर निर्देशित करने के लिए धन्यवाद, Office पर संख्याएँ एकत्रित करने के लिए रवि पिंजला, और SQL पर इसे ट्रायल करने के लिए रॉबर्ट रेज़लर।