JEP ड्राफ्ट: हटाने के लिए sun.misc.unsafe में memory-access methods को deprecated करना

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

Java की low-level `sun.misc.Unsafe` memory-access methods को `VarHandle` और `MemorySegment` जैसे safer standard APIs के पक्ष में deprecated करने की योजना JVM पर performance और safety के बीच लंबे समय से चले आ रहे तनाव को फिर से उजागर कर रही है। कई लोग मजबूत guarantees और unsafe behavior की स्पष्ट सीमाओं का स्वागत करते हैं, लेकिन अन्य लोग चेतावनी देते हैं कि अनिवार्य bounds checks और “zero-overhead” access के नुकसान से compression, encryption, databases, और trading systems जैसे high-performance workloads प्रभावित हो सकते हैं, और वे native code या दूसरी भाषाओं की ओर जा सकते हैं। यह proposal इस बात पर टिका है कि क्या नए APIs और optional flags undocumented internals पर platform की निर्भरता साफ करते हुए near-Unsafe performance बनाए रख सकते हैं।

JEP का संदर्भ

  • JEP, sun.misc.Unsafe के memory-access methods को deprecated करने और अंततः हटाने का प्रस्ताव रखता है, और उनकी जगह यह उपयोग करने की बात करता है:
    • on-heap memory के लिए VarHandle.
    • off-heap memory के लिए MemorySegment (Foreign Function & Memory API).
  • इन्हें सुरक्षित, performant, stable, और tooling के साथ बेहतर integrated बताया गया है.
  • Deprecation का मतलब लंबा समय-खंड है; removal केवल कई LTS releases के बाद तय है.

Performance और Bounds Checking

  • मुख्य विवाद: VarHandle/MemorySegment हमेशा bounds checks करते हैं, जबकि Unsafe उन्हें avoid कर सकता है.
  • कई posters का तर्क है कि bounds checks की cost 10%+ हो सकती है और कभी-कभी बहुत अधिक, खासकर tight loops में, जैसे:
    • Compression/encryption.
    • Parsing-heavy workloads (जैसे One Billion Row Challenge).
    • Low-level data structures और HFT-like systems.
  • अन्य लोग जवाब देते हैं कि:
    • Modern JITs अक्सर bounds checks को eliminate कर देते हैं.
    • Unsafe अन्य optimizations को inhibit कर सकता है और कभी-कभी worse perform करता है.
  • MemorySegment के लिए checks को elide करने की JIT की क्षमता सीमित है और non-obvious patterns की मांग करती है; कुछ लोग इसे brittle मानते हैं.

Safety, Undefined Behavior, और Integrity

  • Removal के पक्ष में तर्क:
    • Unsafe undefined behavior, crashes, और security issues लाता है.
    • Platform चाहता है integrity: runtime और app को यह पता हो कि invariants कहाँ violate हो सकते हैं.
    • यह unchecked undefined behavior से दूर जाने वाले industry trend के साथ मेल खाता है.
  • आलोचकों का कहना है:
    • Advanced users जानबूझकर safety के बदले speed चुनते हैं.
    • इसे ideology की तरह देखना वास्तविक-world performance जरूरतों को नज़रअंदाज़ करता है.

Alternatives और Workarounds

  • Internal jdk.internal APIs command-line flags (--add-exports) के जरिए उपलब्ध रहेंगी, जिसे एक “middle ground” माना जा रहा है.
  • कुछ लोग native FFI (JNI/Panama) को performance escape hatch के रूप में सुझाते हैं; अन्य लोग call overhead और complexity की ओर इशारा करते हैं.
  • कुछ लोग पूर्ण deprecation के बजाय explicit “no-bounds-check” mode या restricted unbounded MemorySegment का प्रस्ताव रखते हैं.

Ecosystem और Migration Concerns

  • प्रमुख Java data systems (Kafka, Cassandra, Elasticsearch, HBase) पर असर को लेकर चिंताएँ हैं, जो Unsafe पर निर्भर हैं.
  • डर है कि पर्याप्त parity न होने पर:
    • लोग पुराने JDKs पर टिके रहेंगे (जैसे modules के साथ 8/11).
    • performance-sensitive users C++, Rust, Go, या C# की ओर चले जाएंगे.
  • अन्य लोग तर्क देते हैं कि अधिकांश libraries negligible impact के साथ migrate कर सकती हैं और केवल code का एक बहुत छोटा हिस्सा ही वास्तव में Unsafe-level semantics की ज़रूरत रखता है.