Rascunho da JEP: Deprecar métodos de acesso à memória em sun.misc.unsafe para remoção

Artigo original ↗ Discussão no Hacker News ↗

O plano do Java de descontinuar os métodos de acesso à memória de baixo nível de `sun.misc.Unsafe` em favor de APIs padrão mais seguras, como `VarHandle` e `MemorySegment`, está reacendendo tensões de longa data entre desempenho e segurança na JVM. Muitos acolhem garantias mais fortes e limites mais claros em torno de comportamentos inseguros, mas outros alertam que a verificação obrigatória de limites e a perda de acesso “zero-overhead” podem prejudicar cargas de trabalho de alto desempenho, como compressão, criptografia, bancos de dados e sistemas de negociação, possivelmente empurrando-as para código nativo ou outras linguagens. A proposta depende de saber se as novas APIs e flags opcionais podem preservar um desempenho próximo ao do `Unsafe` enquanto limpam a dependência da plataforma em internos não documentados.

Contexto da JEP

  • A JEP propõe descontinuar e, por fim, remover os métodos de acesso à memória de sun.misc.Unsafe, em favor de:
    • VarHandle para memória no heap.
    • MemorySegment (Foreign Function & Memory API) para memória fora do heap.
  • Esses são apresentados como seguros, performáticos, estáveis e melhor integrados com ferramentas.
  • A descontinuação implica um longo prazo; a remoção só está prevista depois de várias versões LTS.

Desempenho e verificação de limites

  • A controvérsia central: VarHandle/MemorySegment sempre fazem verificação de limites, enquanto Unsafe pode evitá-la.
  • Vários participantes argumentam que a verificação de limites pode custar 10%+ e, às vezes, muito mais em loops apertados, especialmente em:
    • Compressão/criptografia.
    • Cargas de trabalho com muito parsing (por exemplo, One Billion Row Challenge).
    • Estruturas de dados de baixo nível e sistemas semelhantes a HFT.
  • Outros contrapõem que:
    • JITs modernos frequentemente eliminam verificações de limites.
    • Unsafe pode inibir outras otimizações e às vezes ter desempenho pior.
  • A capacidade do JIT de eliminar verificações para MemorySegment é limitada e requer padrões não óbvios; alguns consideram isso frágil.

Segurança, comportamento indefinido e integridade

  • Argumentos a favor da remoção:
    • Unsafe introduz comportamento indefinido, falhas e problemas de segurança.
    • A plataforma quer integridade: o runtime e a aplicação devem saber onde invariantes podem ser violadas.
    • Isso se alinha à tendência da indústria de se afastar de comportamento indefinido sem verificação.
  • Críticos dizem:
    • Usuários avançados trocam conscientemente segurança por velocidade.
    • Tratar isso como ideologia ignora necessidades reais de desempenho.

Alternativas e contornos

  • APIs internas jdk.internal continuarão acessíveis por flags de linha de comando (--add-exports), vistas como um “meio-termo”.
  • FFI nativo (JNI/Panama) é sugerido por alguns como uma saída para desempenho; outros observam o custo de chamada e a complexidade.
  • Alguns propõem um modo explícito “sem verificação de limites” ou um MemorySegment restrito e sem limites, em vez de uma descontinuação completa.

Preocupações com o ecossistema e a migração

  • Há receios sobre o impacto em grandes sistemas de dados Java (Kafka, Cassandra, Elasticsearch, HBase) que dependem de Unsafe.
  • O medo é que uma paridade insuficiente:
    • Incentive permanecer em JDKs mais antigos (como 8/11 e módulos).
    • Empurre usuários sensíveis a desempenho para C++, Rust, Go ou C#.
  • Outros argumentam que a maioria das bibliotecas pode migrar com impacto desprezível e que apenas uma pequena fração do código realmente precisa de semântica no nível de Unsafe.