5μs में JIT कोड संकलन

मूल लेख ↗ Hacker News चर्चा ↗

डेटाबेस के लिए JIT compilation पर फिर से विचार किया जा रहा है, ultra-fast “copy-and-patch” approaches के साथ जो microseconds में machine code बना सकती हैं, LLVM की भारी latency से बचते हुए भी interpretation की तुलना में पर्याप्त speedups देती हैं। टिप्पणीकार इन performance gains को सख्त W^X policies ढीली करने से जुड़ी security चिंताओं, JIT के complexity और attack surface (विशेषकर untrusted inputs के लिए), तथा उन सीमित domains के मुकाबले तौलते हैं जहाँ added portability और maintenance burden के बावजूद JIT सार्थक है। कई लोग lighter-weight JIT frameworks, Common Lisp जैसी भाषाओं में manual JIT techniques, और यहाँ तक कि LLM-assisted code generation को अधिक practical specialized JITs बनाने के तरीके के रूप में देखते हैं.

JIT और W^X की सुरक्षा

  • एक पक्ष का तर्क है कि JIT स्वाभाविक रूप से कम सुरक्षित है क्योंकि इसके लिए writable और executable memory चाहिए, जिससे सख्त W^X नीतियाँ कमजोर होती हैं और अधिक शक्तिशाली exploits संभव हो जाते हैं।
  • दूसरे कहते हैं कि आधुनिक JIT आम तौर पर RW pages आवंटित करते हैं, कोड लिखते हैं, फिर उन्हें RX में बदल देते हैं, इसलिए प्रति mapping W^X बना रहता है।
  • इस पर बहस है कि क्या इसके “system-wide implications” हैं या यह सिर्फ per-process hardening का चुनाव है; कुछ कहते हैं कि OS को वैसे भी ऐसी permissions संभालनी पड़ती हैं, जबकि अन्य जोर देते हैं कि dynamic code execution की अनुमति देने से bugs का प्रभाव बढ़ जाता है।
  • ऐसे platforms के उदाहरण दिए जाते हैं जो JIT को बहुत सीमित करते हैं (iOS, GrapheneOS) और bytecode verification तथा hardware memory tagging जैसी तकनीकों के उदाहरण भी दिए जाते हैं, जिनसे JIT को अधिक सुरक्षित बनाया जा सकता है।
  • कई टिप्पणियाँ नोट करती हैं कि JIT host process के attack surface को बढ़ाते हैं (खासकर जब untrusted input चल रहा हो, जैसे browsers या DB queries), लेकिन प्रक्रिया के पास पहले से जो क्षमताएँ हैं, उनसे नई क्षमताएँ नहीं देते।
  • ROP और इसी तरह की techniques का हवाला देकर तर्क दिया जाता है कि यदि कोई process किसी भी code को execute कर सकती है, तो JIT हो या न हो, arbitrary code execution व्यावहारिक रूप से संभव है।

JIT design, performance, और LLVM बनाम lightweight approaches

  • कई टिप्पणियाँ जोर देती हैं कि LLVM-आधारित JITs की latency बहुत अधिक होती है और वे उन workloads के लिए अनुपयुक्त हो सकते हैं जिन्हें बहुत तेज़ compilation चाहिए (जैसे Postgres queries)।
  • Lightweight JIT approaches—copy-and-patch templates, छोटे libraries (जैसे SLJIT, GNU Lightning, AsmJit), या custom backends—कम optimizations के बदले बहुत कम compile time देती हैं।
  • लिंक किए गए posts में चर्चा किए गए benchmarks दिखाते हैं कि साधारण JITs interpretation की तुलना में negligible compile time के साथ meaningful speedups दे सकते हैं, जबकि LLVM को compile करने में दसियों milliseconds लग सकते हैं।
  • database-focused टिप्पणियाँ जोर देती हैं कि query-plan optimization (जैसे join ordering) JIT से कहीं अधिक महत्वपूर्ण है; Postgres का वर्तमान JIT granularity (per expression, pipeline नहीं) एक मूलभूत सीमा माना जाता है।

क्या template-based codegen “real” JIT है?

  • कुछ लोग इस approach को “सिर्फ assembly templates” कहकर खारिज करते हैं, लेकिन अन्य इसका प्रतिवाद करते हैं कि:
    • Non-optimizing compilers भी compilers ही होते हैं।
    • Copy-and-patch एक standard, वैध JIT technique है।
  • ऐसे उदाहरण दिए जाते हैं जहाँ बहुत simple codegens (कोई register allocation नहीं, stack का भारी उपयोग) highly optimized -O3 binaries से केवल कुछ गुना धीमे होते हैं, लेकिन interpreters से बहुत तेज़ होते हैं।

Common Lisp और manual JIT

  • Common Lisp implementations को एक middle ground के रूप में चर्चा की जाती है:
    • कुछ सभी code को eagerly compile करते हैं; अन्य bytecode plus optional native compilation का समर्थन करते हैं।
    • eval और compile-on-load को JIT का एक रूप माना जाता है।
    • REPL use के लिए interpreter और compiler के बीच switch करने के toggles होते हैं, जो compile time बनाम execution speed का trade-off देते हैं।
  • एक “manual JIT” शैली—स्पष्ट रूप से यह चुनना कि speed के लिए क्या compile करना है—को एक व्यावहारिक और सरल compromise के रूप में सराहा जाता है।

JIT और जटिल प्रणालियाँ लिखने में AI की भूमिका

  • विचार बहुत तेज़ी से अलग-अलग हैं:
    • कुछ लोग कहते हैं कि वर्तमान models जटिल domains में खराब code बनाते हैं, और मुख्यतः boilerplate, CRUD, APIs wiring, तथा simple bug-finding के लिए उपयुक्त हैं।
    • अन्य रिपोर्ट करते हैं कि AI का उपयोग करके complex components (JITs सहित) scaffold करने में बड़ी productivity gains मिली हैं, जहाँ एक हफ्ते का काम कुछ घंटों में हो जाता है, बशर्ते एक सक्षम engineer tasks को तोड़े और output की समीक्षा करे।
  • इस पर बहस है:
    • अभी भी domain expertise कितनी आवश्यक है (कई लोग कहते हैं “बहुत अधिक”)।
    • क्या AI-generated code quality वस्तुनिष्ठ रूप से खराब है या केवल शैलीगत रूप से अलग।
    • गैर-विशेषज्ञ users द्वारा सतही रूप से अच्छा लेकिन fragile AI-written code shipping करने का जोखिम।

अन्य अनुप्रयोग और अवलोकन

  • टिप्पणीकर्ता firewall और on-the-fly eBPF generation के लिए इसी तरह के stencil-based JIT ideas का उपयोग सुझाते हैं।
  • Regex engines, ऐतिहासिक BASIC और Lisp systems, तथा आधुनिक DBMSs को JIT के क्लासिक या स्वाभाविक domains के रूप में उल्लेख किया गया है।
  • thread में formally verified interpreters और signed static binaries को JIT और native code के एक चरम security alternative के रूप में संक्षेप में छुआ गया है।