Meta का jemalloc में नया निवेश और open source सहयोग को मज़बूत करना

• उच्च-प्रदर्शन मेमोरी allocator jemalloc, Meta software stack में Linux kernel और compiler के साथ एक बुनियादी component के रूप में core infrastructure की भूमिका निभाता रहा है
• पिछले कुछ वर्षों में, jemalloc development का मार्गदर्शन करने वाले मुख्य engineering principles से धीरे-धीरे दूर होने के कारण technical debt जमा होती गई और प्रगति धीमी पड़ गई
• community feedback को स्वीकार करते हुए और project founder Jason Evans सहित सदस्यों के साथ चर्चा के बाद, मूल open source repository को फिर से सक्रिय (unarchived) किया गया
• आगे चलकर technical debt को साफ करने, Huge-Page allocator में सुधार, memory efficiency बढ़ाने और AArch64 optimization पर ध्यान केंद्रित करने की योजना है
• Meta ने jemalloc की दीर्घकालिक stewardship के प्रति अपनी प्रतिबद्धता की फिर से पुष्टि की है और community के साथ सहयोग के ज़रिए project को आगे बढ़ाने की दिशा में रुख किया है

---

jemalloc की भूमिका और महत्व

• jemalloc एक उच्च-प्रदर्शन मेमोरी allocator है, जो Meta software stack में लगातार उच्च leverage देने वाला component रहा है
• यह hardware और ऊपर की software layers में होने वाले बदलावों के अनुसार लगातार खुद को ढालता रहा है, और Linux kernel और compiler के साथ मिलकर Meta infrastructure की स्थिरता और performance में योगदान देता है

सिद्धांतों से विचलन और आत्ममंथन

• बुनियादी software components को व्यवहारिकता और सिद्धांतों के बीच सबसे ऊँचे स्तर की कठोरता की आवश्यकता होती है
• jemalloc द्वारा प्रदान किए जाने वाले उच्च leverage के कारण अल्पकालिक लाभ लेने का प्रलोभन मौजूद रहता है, और इसे ठुकराने के लिए संगठन-स्तर की मज़बूत self-discipline की ज़रूरत होती है
• पिछले कुछ वर्षों में jemalloc development का नेतृत्व करने वाले मुख्य engineering principles से क्रमिक विचलन हुआ
• कुछ निर्णयों ने तुरंत लाभ दिया, लेकिन उनके परिणामस्वरूप पैदा हुई technical debt ने प्रगति को बाधित किया
• community feedback को गंभीरता से लिया गया और project founder Jason Evans सहित community members के साथ बैठकें की गईं
• stewardship का jemalloc के दीर्घकालिक स्वास्थ्य पर क्या प्रभाव पड़ा, इस पर गहराई से विचार किया गया और approach में बदलाव साझा किया गया
• technical debt हटाने और jemalloc के लिए दीर्घकालिक roadmap को फिर से बनाने का काम शुरू किया गया

नया अध्याय: repository का archive हटना और आगे की योजना

• community के साथ बातचीत के परिणामस्वरूप, मूल jemalloc open source repository को फिर से सक्रिय (unarchived) किया गया
• Meta अब भी project की steward की भूमिका निभा सकेगा, और maintenance burden कम करने तथा codebase को modernize करने पर ध्यान देगा
  • technical debt की सफाई: refactoring और सुधारों के माध्यम से इसे सभी users के लिए efficient, reliable और उपयोग में आसान बनाए रखना
  • Huge-Page allocator (HPA): Transparent Hugepages (THP) का बेहतर उपयोग करके CPU efficiency बढ़ाना
  • memory efficiency: packing, caching और purging mechanisms में सुधार के ज़रिए memory efficiency को optimize करना
  • AArch64 optimization: ARM64 platform पर default state में अच्छा performance सुनिश्चित करना

community के साथ सहयोग को मज़बूत करना

• Meta ने कार्रवाइयों के ज़रिए भरोसा बनाने पर ज़ोर दिया और jemalloc के स्वस्थ विकास को लक्ष्य बताया
• community की feedback और भागीदारी का स्वागत किया गया, और साथ मिलकर jemalloc का भविष्य बनाने की उम्मीद जताई गई
• open source ecosystem में sustainable collaboration और विकास को आगे बढ़ाया जाएगा

[GN⁺]

Hacker News की राय

• Facebook में काम करते समय, jemalloc के purging mechanism को बेहतर बनाने के लिए kernel patch मेंटेन किया था
  kernel या security community में यह खास लोकप्रिय नहीं था, लेकिन benchmarks में इसकी efficiency अच्छी थी
  समस्या यह थी कि memory को किसी दूसरे thread को फिर से allocate करते समय zeroing होता था, जिससे cache locality और performance पर असर पड़ता था
  उसी security domain के भीतर memory को reuse करते समय यह अनावश्यक व्यवहार था, लेकिन ‘security domain’ की सीमा कहाँ तक मानी जाए इस पर सहमति बनाना मुश्किल था
  संबंधित चर्चा Linux Kernel mailing list में है

  • अब भी उस patch का ज़िक्र होना हैरान करता है
    HHVM में उस patch के लागू होने से पहले और बाद में व्यापक benchmarks किए गए थे, लेकिन system level पर कोई statistically significant अंतर नहीं था
    कुछ microbenchmarks में सुधार रहा होगा, लेकिन पूरे system performance पर असर नहीं था, इसलिए उसे kernel में शामिल नहीं किया गया
  • जानना चाहूँगा कि कौन-सा metric बेहतर हुआ था
  • अगर cgroup के भीतर processes के बीच memory contents लीक होना स्वीकार्य माना जाए, तो यह खतरनाक सोच लगती है

• हाल में Microsoft के mimalloc को LD_PRELOAD के साथ इस्तेमाल करके 1GB huge page का उपयोग किया
  memory-intensive program में लगभग 20% performance improvement मिला
  Linux पर open source MS library से performance बढ़ाना थोड़ा अजीब लगता है
  लगता है malloc क्षेत्र में और competition होना चाहिए

  • कई allocators टेस्ट किए, और latest tcmalloc ने time और memory दोनों में सबसे अच्छे नतीजे दिए
    ऐप्स Rust में लिखे गए थे, और ज़्यादातर statically linked थे
    उदाहरण के लिए app1 में glibc की तुलना में tcmalloc ने RSS 35% घटाया और processing time 30% कम किया
    पूरे नतीजे tcmalloc repository के आधार पर टेस्ट किए गए थे
  • पहले Dr. Dobbs या BYTE जैसी magazines में custom memory allocator के बहुत ads होते थे
    Turbo Pascal तक में memory allocator को सीधे define करने के लिए API दिया गया था
    अंततः “one size fits all” approach की सीमा बहुत पहले से साफ थी
  • GC languages का एक फायदा यह है कि allocation/free cost bundled होने से profiling में चीज़ें अधिक साफ दिखती हैं
  • पुराने Apache Portable Runtime का memory pool concept काफ़ी प्रभावशाली था
    हर request के लिए एक pool बनता था, और request खत्म होने पर पूरा pool एक साथ free हो जाता था
    लगता है malloc में भी इस दिशा में आगे बढ़ने की काफी गुंजाइश है
  • कुछ मामलों में malloc से बेहतर यह हो सकता है कि सीधे mmap से huge page map किया जाए
    अगर allocation pattern सरल हो, तो third-party malloc से भी बेहतर नतीजे मिल सकते हैं
    लोग malloc को किसी जादुई black box की तरह देखते हैं, लेकिन वास्तव में वह इतना असाधारण नहीं है

• हमारी टीम ने 2 साल पहले glibc malloc से jemalloc पर migration किया था
  Python service में memory usage 15~20% कम हुआ
  लेकिन container environment में oversize_threshold को tune करना महत्वपूर्ण था — गलत setting पर OOM हो सकता है
  जानना चाहूँगा कि long-running services में jemalloc और mimalloc की तुलना वाला कोई benchmark है क्या

• संबंधित पढ़ाई के लिए Jemalloc Postmortem और
  Jemalloc Repositories Are Archived की सिफारिश है

• क्या यह बदलाव कहीं global memory shortage की वजह से तो नहीं, यह जानने की जिज्ञासा है
  शायद “memory allocator बदलकर सालाना लाखों डॉलर की बचत” जैसी गणना निकल सकती है

  • Facebook 10 साल पहले से ही ऐसे micro-optimizations से cost reduction करने की कोशिश करता रहा है
    सिर्फ 0.1% efficiency improvement से भी हर महीने 1 लाख डॉलर की बचत संभव थी
    बचत का मुख्य कारण cooling cost (HVAC) और कम servers खरीदने की ज़रूरत थी
    अब memory saving भी बड़ा मुद्दा है, लेकिन तब ऐसा नहीं था
  • सिर्फ cost ही नहीं, बल्कि memory supply delay की भरपाई के लिए efficiency improvement भी महत्वपूर्ण है
  • Meta में लाखों डॉलर के scale पर savings ढूँढना आम बात है
    अगर असर हज़ारों servers पर पड़े, तो छोटा सुधार भी बड़ी संख्या बन जाता है
    ऐसी quantitative improvement culture वहाँ जमी हुई है
  • उस कंपनी की reputation को देखते हुए, यह सिर्फ memory shortage से बढ़कर कोई जटिल कारण भी हो सकता है
  • यह वह समय है जब LLM, power, और server memory efficiency लगातार अधिक महत्वपूर्ण हो रहे हैं
    सिर्फ 10% तेज़ होना भी LLM competition में बढ़त दे सकता है
    performance improvement के लिए incentive बहुत बड़ा है

• ऑस्ट्रेलिया में low-level programming करते हुए layoff का सामना किया था
  मुझे ऐसे problems सुलझाना सच में पसंद है, लेकिन local market ज़्यादातर React CRUD पर केंद्रित है, यह अफ़सोस की बात है

  • AU में low-level data processing से जुड़ी hiring चल रही है। bio में link है
  • मैं भी ऑस्ट्रेलिया में React CRUD ही करता रहा और यही सोचता था
  • अगर remote work देख रहे हों, तो Igalia jobs page दिलचस्प हो सकता है
  • HFT firms (IMC trading) भी ऐसे low-level optimization काम बहुत करती हैं, और अभी ऑस्ट्रेलिया में hiring कर रही हैं
  • SIG भी Sydney में संबंधित positions के लिए भर्ती कर रहा है: SIG Careers

• World Bank funding वाले startup project में Ruby + jemalloc को production में deploy किया था
  speed और memory efficiency में साफ़ सुधार दिखा, जिससे AWS cost काफ़ी घट गई
  यह 8 साल पहले की बात है, इसलिए हैरानी होती है कि jemalloc अब तक standard क्यों नहीं बन पाया

  • ज़्यादातर मामलों में वजह बस जानकारी की कमी या जड़ता होती है
    जो systems पहले से production में चल रहे हों, उन्हें बदलना आसान नहीं होता, भले ही फ़ायदा स्पष्ट हो

• jemalloc का इस्तेमाल करके memory leak के कारण को trace करने का एक मामला भी है
  GOV.UK tech blog post देखें

• Meta ने अपने fork में चल रहे काम को बड़े पैमाने पर merge किया है
  इसे PR #2863 में देखा जा सकता है

• jemalloc की timeline या history को समेटने वाला कोई material है क्या, यह जानना चाहूँगा
  यह एक open source project है, फिर भी Meta के पास इसकी lead क्यों है, यह सवाल है

  • इसके creator Jason Evans ने पिछले साल पूरी पृष्ठभूमि का सार दिया था
    Jemalloc Postmortem blog देखें
  • पिछले 5 साल के commits देखें तो top 6 में से 4 लोग Meta employees हैं
    बाकी 2 भी संभव है कि निजी रूप से Meta से जुड़े हों