Pemeriksaan Fungsi Tanpa Alokasi di OxCaml yang Perlu Dipelajari Lebih Banyak Bahasa

• OxCaml, superset OCaml dari Jane Street, memungkinkan deklarasi ke compiler bahwa seluruh pohon pemanggilan fungsi dilarang melakukan alokasi heap dengan [@zero_alloc]
• Jika terjadi alokasi di jalur pemanggilan yang dideklarasikan, hal itu langsung terlihat sebagai kegagalan kompilasi, sehingga regresi bisa dicegah lebih cepat daripada mencarinya nanti dengan profiler
• Di C, C++, Java, Go, C#, Rust, Zig, OCaml, dan lainnya, pendekatan yang umum biasanya berpusat pada mencari lalu mengurangi alokasi di hot path dengan profiler
• Kode hot path bisa kembali menimbulkan alokasi hanya karena perubahan kecil, sehingga jika konteks optimasi sebelumnya terlupakan, investigasi yang sama harus diulang
• Konvensi penerusan allocator di Zig atau sebagian Rust modern juga membantu, tetapi pemeriksaan compiler adalah pengaman yang lebih langsung daripada sekadar konvensi

---

Bagaimana [@zero_alloc] mengubah pengelolaan alokasi

• OxCaml adalah superset OCaml dari Jane Street dan mendukung pernyataan bahwa sebuah fungsi tidak melakukan alokasi ke heap
• Jika [@zero_alloc] ditempelkan pada sebuah fungsi, compiler akan memeriksa apakah bukan hanya fungsi itu, tetapi juga pohon pemanggilan di bawahnya, melakukan alokasi heap atau tidak
• Jika alokasi terjadi di dalam pohon pemanggilan itu, build akan gagal dan compiler akan memberi tahu terjadinya alokasi
• Secara teori pemeriksaan serupa mungkin bisa dibuat lewat analisis statis, tetapi di antara bahasa arus utama, jarang ada yang memasukkan fitur seperti ini langsung ke compiler berdasarkan ringkasan yang dihasilkan

Perbedaannya dengan pendekatan berbasis profiler

• Di bahasa lain, umumnya alokasi ditemukan lebih dulu dengan profiler, lalu dihapus atau dikurangi, terutama alokasi di dalam loop yang berjalan jutaan kali
• C, C++, Java, Go, C#, Rust, Zig, dan OCaml disebut sebagai contoh pendekatan yang berpusat pada profiler
• Mengubah satu baris saja di hot path dapat memasukkan alokasi lagi, dan untuk mencari penyebabnya, pengembang harus kembali ke profiler
• Di Zig atau sebagian Rust modern, regresi dapat dikurangi dengan cara tidak meneruskan allocator ke fungsi, tetapi ini bergantung pada konvensi
• Perbedaan [@zero_alloc] adalah bahwa bukan analisis setelah kejadian atau aturan tim yang menghentikan regresi alokasi, melainkan compiler yang memblokirnya saat build

[GN⁺]

Komentar di Lobste.rs

• Saya memahami alasan allocator diteruskan sebagai argumen fungsi di Zig adalah agar fungsi yang tidak menerima allocator sebagai argumen tidak bisa melakukan alokasi heap; apakah itu benar?
  Jika pernyataan “konvensi bisa diabaikan” memang benar, rasanya itu tidak sesuai dengan niatnya

  • Benar, pada akhirnya itu hanya konvensi.
    Di dalam fungsi pun allocator bisa dibuat baru seperti halnya di luar fungsi

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

  • D sudah memiliki nogc sejak cukup lama, dan menurut saya semantiknya mirip karena GC-lah yang menangani alokasi
    https://dlang.org/phobos/dmd_nogc.html
    Dulu sempat ditambahkan juga pengecualian nogc secara eksperimental, tetapi saya belum memeriksa status atau implementasinya saat ini
    https://dlang.org/changelog/2.079.0.html#dip1008

• Menggunakan core saja di Rust juga merupakan salah satu cara menghindari alokasi

  • “Menghindari alokasi” hanya sebagian dari ceritanya.
    Pendekatan itu pada akhirnya lebih dekat dengan “kendalikan dependensi” atau “periksa seluruh call graph secara manual”.
    Fokus artikel ini adalah bagaimana alat seperti compiler secara statis menegakkan suatu properti, dan menyediakan alur kerja yang produktif untuk menemukan titik tempat properti itu dilanggar

• D memiliki @nogc, dan setelah itu masalahnya adalah hanya menggunakan abstraksi yang bisa dikendalikan langsung dengan pola alokasi yang jelas

• Karena kemampuan membuat judul artikel yang deskriptif tampaknya sudah hilang, saya tambahkan: intinya adalah fitur untuk menempelkan [@zero_alloc] pada fungsi, lalu membuat compiler menolak program jika pohon pemanggilan fungsi tersebut menyentuh heap

• Saya penasaran apakah pendekatan seperti ini juga bisa diterapkan pada berbagai kondisi seperti “tidak melempar exception atau panic”, “tanpa lock”, atau “selalu berhenti”