JEP Draft: Deprecate memory-access methods in sun.misc.unsafe for removal

Original Article ↗ Hacker News Discussion ↗

Java’s plan to deprecate the low-level `sun.misc.Unsafe` memory-access methods in favor of safer standard APIs like `VarHandle` and `MemorySegment` is reigniting long‑running tensions between performance and safety on the JVM. Many welcome stronger guarantees and clearer boundaries around unsafe behavior, but others warn that mandatory bounds checks and loss of “zero‑overhead” access could hurt high‑performance workloads such as compression, encryption, databases, and trading systems, potentially pushing them toward native code or other languages. The proposal hinges on whether new APIs and optional flags can preserve near‑Unsafe performance while cleaning up the platform’s reliance on undocumented internals.

Context of the JEP

  • JEP proposes deprecating and eventually removing sun.misc.Unsafe memory-access methods, in favor of:
    • VarHandle for on-heap memory.
    • MemorySegment (Foreign Function & Memory API) for off-heap memory.
  • These are positioned as safe, performant, stable, and better integrated with tooling.
  • Deprecation implies long runway; removal is slated only after multiple LTS releases.

Performance and Bounds Checking

  • Core controversy: VarHandle/MemorySegment always perform bounds checks, whereas Unsafe can avoid them.
  • Several posters argue bounds checks can cost 10%+ and sometimes much more in tight loops, especially in:
    • Compression/encryption.
    • Parsing-heavy workloads (e.g., One Billion Row Challenge).
    • Low-level data structures and HFT-like systems.
  • Others counter that:
    • Modern JITs often eliminate bounds checks.
    • Unsafe can inhibit other optimizations and sometimes performs worse.
  • JIT’s ability to elide checks for MemorySegment is constrained and requires non-obvious patterns; some consider this brittle.

Safety, Undefined Behavior, and Integrity

  • Pro-removal arguments:
    • Unsafe introduces undefined behavior, crashes, and security issues.
    • The platform wants integrity: the runtime and app should know where invariants may be violated.
    • Aligns with industry trend away from unchecked undefined behavior.
  • Critics say:
    • Advanced users knowingly trade safety for speed.
    • Treating this as ideology ignores real-world performance needs.

Alternatives and Workarounds

  • Internal jdk.internal APIs will remain accessible via command-line flags (--add-exports), seen as a “middle ground.”
  • Native FFI (JNI/Panama) is suggested by some as a performance escape hatch; others note call overhead and complexity.
  • Some propose an explicit “no-bounds-check” mode or restricted unbounded MemorySegment, rather than full deprecation.

Ecosystem and Migration Concerns

  • Worries about impact on major Java data systems (Kafka, Cassandra, Elasticsearch, HBase) that rely on Unsafe.
  • Fear that inadequate parity will:
    • Encourage sticking to older JDKs (as with 8/11 and modules).
    • Push performance-sensitive users toward C++, Rust, Go, or C#.
  • Others argue most libraries can migrate with negligible impact and that only a tiny fraction of code truly needs Unsafe-level semantics.