फ्रेम पॉइंटर की वापसी

Brendan की साइट: शुरुआत

• Brendan Gregg के ब्लॉग होमपेज पर system performance, BPF tools, Linux performance आदि से जुड़े कई विषय शामिल हैं।
• हाल की पोस्टों में फ्रेम पॉइंटर की वापसी, eBPF डॉक्यूमेंट्री, और eBPF observability tools सुरक्षा tools नहीं हैं, जैसे विषय शामिल हैं।
• ब्लॉग तकनीकी सामग्री के साथ-साथ Brendan द्वारा भाग लिए गए विभिन्न conferences और presentations की जानकारी भी साझा करता है।

फ्रेम पॉइंटर की वापसी

• जिन systems में फ्रेम पॉइंटर नहीं होते, उनमें stack trace libc लेयर पर रुक जाता है, जिससे application frames छूट जाते हैं।
• Fedora और Ubuntu ने libc को डिफ़ॉल्ट रूप से फ्रेम पॉइंटर सहित compile करने वाले versions जारी करके इस समस्या को हल किया।
• फ्रेम पॉइंटर का उपयोग external profilers और debuggers द्वारा किया जाता है, और इन्हें flame graphs के जरिए visualise किया जाता है।

फ्रेम पॉइंटर क्या है?

• x86-64 ABI दस्तावेज़ के अनुसार CPU register %rbp का उपयोग stack frame के "base pointer" के रूप में किया जा सकता है।
• यह तकनीक stack tracing के लिए व्यापक रूप से इस्तेमाल होती है, और Linux perf तथा eBPF आदि द्वारा उपयोग की जाती है।

2004: फ्रेम पॉइंटर हटाना

• 2004 में gcc डेवलपर Roger Sayle ने फ्रेम पॉइंटर generation को बंद करने वाला बदलाव आगे बढ़ाया।
• इस बदलाव से performance में सुधार हुआ, लेकिन eBPF के आने के बाद आज कुछ debuggers/profilers को इससे समस्या होती है।

2005-2023: टूटे हुए profilers की सर्दी

• फ्रेम पॉइंटर हटाने वाला बदलाव x86-64 पर भी लागू किया गया, लेकिन इस architecture में registers अधिक होने के कारण बड़ा लाभ नहीं मिला।
• इसके कारण कई debuggers/profilers ठीक से काम नहीं कर पाए।

2014: Java in Flames

• Netflix में शामिल होने पर यह पाया गया कि Java में फ्रेम पॉइंटर support की कमी सभी application stacks को तोड़ रही थी।
• इस समस्या को हल करने के लिए JVM c2 compiler के लिए एक संशोधन विकसित किया गया।

2015-2020: ओवरहेड

• हर चीज़ में फ्रेम पॉइंटर जोड़ने का performance overhead आम तौर पर 1% से कम होता है।
• कुछ खास microbenchmarks में यह overhead 10% तक पहुंच सकता है।

2022: upstream प्रयास

• इससे संकेत मिलता है कि Google, Meta, Netflix जैसी बड़ी कंपनियां पहले से ही हर चीज़ में फ्रेम पॉइंटर enable कर चुकी हैं।
• इन बदलावों को सभी के हित में डिफ़ॉल्ट बनाने में कई कठिनाइयाँ हैं।

2023, 2024: Fedora और Ubuntu में फ्रेम पॉइंटर

• Fedora ने फ्रेम पॉइंटर को फिर से enable करने का प्रस्ताव स्वीकार कर लिया।
• Ubuntu ने भी 24.04 LTS version में डिफ़ॉल्ट रूप से फ्रेम पॉइंटर enable किया।

2034 के बाद: फ्रेम पॉइंटर से आगे

• stack tracing के कई तरीके हैं, जिनमें LBR, BTS, AET, DWARF, eBPF stack walking, ORC, SFrames, shadow stacks आदि शामिल हैं।
• भविष्य में SFrames या shadow stacks का उपयोग सभी stack traces के लिए किया जा सकता है।

निष्कर्ष

• फ्रेम पॉइंटर की वापसी CPU flame graphs को अधिक अर्थपूर्ण बनाती है, Off-CPU flame graphs को पहली बार काम करने योग्य बनाती है, और नई संभावनाओं को खोलती है।
• यह continuous profilers के लिए भी एक जीत है, क्योंकि profiler को पूरी तरह काम करने के लिए अब ग्राहकों को OS बदलने के लिए मनाने की ज़रूरत नहीं होगी।

GN⁺ की राय

• फ्रेम पॉइंटर की वापसी system performance analysis और debugging में बहुत मददगार साबित होगी। खासकर जटिल software systems में समस्याओं की पहचान और performance optimisation के लिए यह एक ज़रूरी tool है।
• यह बदलाव open source community के सहयोग और योगदान के महत्व को भी दिखाता है। Fedora और Ubuntu का निर्णय दूसरे distributions को भी प्रभावित कर सकता है, जिससे पूरे Linux ecosystem में सकारात्मक बदलाव आ सकता है।
• फ्रेम पॉइंटर को फिर से अपनाना performance degradation और debugging की आसानी के बीच संतुलन बनाने का सवाल है। ऐसे निर्णयों को वास्तविक production environments में performance testing और analysis के ज़रिए बेहतर समझा जा सकता है।
• तकनीकी पृष्ठभूमि वाले users के लिए यह बदलाव दिलचस्प हो सकता है, और system performance सुधार में रुचि रखने वाले developers या system administrators के लिए उपयोगी जानकारी देता है।
• अगर फ्रेम पॉइंटर जैसी सुविधा देने वाली अन्य technologies या tools हों, तो उदाहरण के लिए Intel का VTune Profiler या AMD का uProf जैसे hardware-based profilers इस्तेमाल किए जा सकते हैं। ये tools फ्रेम पॉइंटर के बिना भी performance analysis संभव बनाते हैं।

[GN⁺]

Hacker News राय

• 2000 के दशक की शुरुआत में जब stack frame pointer को हटाने की प्रथा फैलनी शुरू हुई, उस समय का अनुभव
  • लेखक उस समय computer science की पढ़ाई कर रहे थे, और उनका इस्तेमाल किया जाने वाला कंप्यूटर पुराना और कम-प्रदर्शन वाला था।
  • debugging कठिन हो जाने पर, उन्होंने debugging की समस्या से बचने के लिए Python का उपयोग करना शुरू किया।
• Fedora distribution में stack frame pointer को बनाए रखने के लिए किए गए प्रयास
  • यह गलत धारणा थी कि stack frame pointer का overhead बहुत बड़ा होता है, लेकिन वास्तविक overhead 1% से कम है।
• Apple ने ARM architecture में stack trace को हमेशा अर्थपूर्ण बनाए रखा
  • कुछ functions frame record नहीं बना सकते, लेकिन stack trace debug जानकारी के बिना भी उपयोगी रहता है।
• Google में अनुभव और community के साथ 20 साल की बहस
  • libunwind को gperftools पर लागू करने के लिए patching और maintenance का अनुभव साझा किया गया।
• अतीत में -fomit-frame-pointer विकल्प से performance सुधार का अनुभव
  • 32-bit processors पर MySQL और PHP को compile करके hardware लागत कम की गई।
• Virgil programming language में stack frame प्रबंधन का तरीका
  • जब dynamic stack allocation नहीं होता, तब साधारण table lookup से frame size पता किया जा सकता है।
  • metadata decoding को लागू करने वाले code का विवरण।
• stack को 'walk' करने के बजाय RBP और RSP का उपयोग करके दो stack प्रबंधित करने का विचार
  • call stack सिर्फ return addresses की array बन जाने से stack walking की आवश्यकता कम हो जाती है।
• frame pointer के समर्थन से जुड़े अनुभव और विचार साझा किए गए
  • frame pointer को सक्षम करना है या नहीं, यह हर case के आधार पर तय किया जाना चाहिए, और benchmarking महत्वपूर्ण है।
  • build system में इसे पूरे स्तर पर बदल सकने वाली सुविधा का होना महत्वपूर्ण है।
  • SFrame को लेकर उम्मीद, और वर्तमान समस्याओं को हल करने की उसकी संभावनाएँ।
• यह राय कि profiling 20 साल तक समस्या रही और अब जाकर हल हुई
  • frame pointer की अनुपस्थिति कई लोगों के लिए पीड़ादायक थी, और अब Linux को इसे वापस लाते देख ऐसा लगता है कि उनके प्रयासों को मान्यता मिली है।
• system profiling को संभव बनाने वाली mechanism की performance को लेकर शिकायत करना विडंबनापूर्ण है
  • जिस system की वजह से performance समस्याओं की पहचान संभव होती है, उसी की performance पर शिकायत करना premature optimization की पराकाष्ठा है।