अधिक भाषाओं को OxCaml की allocation-free function check से सीखना चाहिए

• Jane Street के OCaml superset OxCaml में [@zero_alloc] के जरिए compiler को यह declare किया जा सकता है कि पूरे function call tree में heap allocation प्रतिबंधित है
• घोषित call path में allocation होने पर यह तुरंत compile failure के रूप में सामने आता है, जिससे profiler के जरिए बाद में खोजने की तुलना में regression को जल्दी रोका जा सकता है
• C, C++, Java, Go, C#, Rust, Zig, OCaml आदि में आम तौर पर hot path में allocations को profiler से खोजकर घटाने का तरीका मुख्य होता है
• hot path code में छोटी-सी बदलाव से भी फिर से allocation आ सकता है; अगर पुराने optimization context को भूल जाएं, तो वही जांच दोहरानी पड़ती है
• Zig या modern Rust के कुछ हिस्सों में allocator pass करने की convention भी मदद करती है, लेकिन convention की तुलना में compiler check ज्यादा सीधा safeguard है

---

[@zero_alloc] allocation management को कैसे बदलता है

• OxCaml Jane Street का OCaml superset है, और यह functions के heap पर allocate न करने के assertion को support करता है
• किसी function पर [@zero_alloc] लगाने पर compiler सिर्फ उस function ही नहीं, बल्कि उसके नीचे के call tree तक heap allocation की जांच करता है
• call tree के अंदर allocation होने पर build fail हो जाता है, और compiler allocation होने की जानकारी देता है
• static analysis से ऐसी मिलती-जुलती जांच बनाने की संभावना है, लेकिन तैयार की गई summaries के आधार पर ऐसी capability को compiler में ही शामिल करने वाली mainstream languages दुर्लभ हैं

profiler-केंद्रित approach से अंतर

• दूसरी languages में आम तौर पर profiler से allocations खोजे जाते हैं, फिर खासकर लाखों बार execute होने वाले loops के अंदर के allocations हटाए या घटाए जाते हैं
• C, C++, Java, Go, C#, Rust, Zig, OCaml आदि को profiler-केंद्रित approach के उदाहरण के रूप में सूचीबद्ध किया गया है
• hot path की एक line बदलने भर से allocation वापस आ सकता है, और वजह खोजने के लिए फिर profiler पर लौटना पड़ता है
• Zig या modern Rust के कुछ हिस्सों में allocator को function में pass न करने के तरीके से regressions घटाए जा सकते हैं, लेकिन यह convention पर निर्भर करता है
• [@zero_alloc] का अंतर यह है कि post-hoc analysis या team rules के बजाय, build time पर compiler allocation regression को रोकता है

[GN⁺]

Lobste.rs की टिप्पणियाँ

• मैं समझता था कि Zig में allocator को function argument के रूप में पास करने की वजह यह है कि जो functions argument के रूप में allocator नहीं लेते, वे heap allocation न कर सकें; क्या यह सही है, जानना चाहूँगा
  अगर “conventions को नज़रअंदाज़ किया जा सकता है” वाली बात वाकई सही है, तो यह इरादे से अलग लगता है

  • सही है, आखिरकार यह सिर्फ़ एक convention ही है
    function के अंदर भी, बाहर की तरह, नया allocator बनाया जा सकता है

• gift link: https://theconsensus.dev/p/2026/…

  • D में काफी समय से nogc मौजूद है, और चूँकि allocation की ज़िम्मेदारी GC संभालता है, मुझे लगता है इसकी semantics मिलती-जुलती है
    https://dlang.org/phobos/dmd_nogc.html
    एक समय experimental तौर पर nogc exceptions भी जोड़े गए थे, लेकिन अभी उनकी स्थिति या implementation मैंने जाँची नहीं है
    https://dlang.org/changelog/2.079.0.html#dip1008

• Rust में सिर्फ़ core इस्तेमाल करना भी allocation से बचने का एक तरीका है

  • “allocation से बचना” कहानी का सिर्फ़ एक हिस्सा है
    वह approach आखिरकार “dependencies को control करो” या “पूरे call graph को manually जाँचो” जैसा है
    लेख का focus इस बात पर है कि compiler जैसे tools किस तरह किसी property को statically enforce करते हैं, और वह property कहाँ टूटती है, इसे productive तरीके से ढूँढने का workflow देते हैं

• D में @nogc है, और उसके बाद बात सिर्फ़ ऐसी सीधे control की जा सकने वाली abstractions इस्तेमाल करने की है जिनके allocation patterns स्पष्ट हों

• article titles को descriptive बनाने की क्षमता खो जाने के कारण जोड़ दूँ: मुख्य बात यह feature है कि किसी function पर [@zero_alloc] लगाएँ, और अगर उस function की call tree heap को छूती है तो compiler program को reject कर दे

• जिज्ञासा है कि क्या यह तरीका “exceptions throw या panic नहीं करता”, “कोई lock नहीं”, “हमेशा terminate करता है” जैसी कई conditions पर भी लागू हो सकता है