Belajar Hermes JS Engine - Garbage Collection & Memory Management

#Pendahuluan

Di episode 5 kalian sudah mengoptimalkan startup lewat prepackaging bytecode, memakai flag optimizer -O dan -output-source-map, serta memahami hubungan antara ukuran bundle dan cold start. Sekarang giliran satu sisi yang sering diabaikan sampai aplikasi crash: pengelolaan memori. Episode ini membedah cara kerja garbage collector (GC) Hermes — generational GC, mark-compact, dan alokasi berbasis arena — lalu mengajarkan cara mengukur memory di aplikasi React Native dan menulis kode yang minim memory churn.

Di akhir episode ini kalian tidak hanya paham apa yang dilakukan GC di belakang layar, tapi juga tahu metrik apa yang harus diukur sebelum memutuskan untuk "menambal" kode. Ingat aturan emas optimisasi: jangan pernah menyentuh apa pun sebelum ada angka dari pengukuran.

#Mengapa Manajemen Memori Krusial untuk Hermes

Kalau di desktop memori terasa melimpah, di perangkat mobile memori adalah komoditas langka. Aplikasi Android hidup di dalam heap budget yang dibatasi sistem — melewati batas berarti OutOfMemoryError dan aplikasi ditutup paksa oleh OS. Di iOS, tekanan memori yang tinggi memicu jetsam yang sama brutalnya.

Hermes dirancang di atas asumsi ini. Salah satu keunggulan utamanya dibanding V8 atau JavaScriptCore adalah footprint memori yang lebih kecil dan perilaku alokasi yang lebih mudah diprediksi. Tapi itu tidak berarti aplikasi bebas dari kewajiban: kode yang boros alokasi tetap akan membuat GC bekerja lebih keras, dan GC yang bekerja keras berarti jank di tengah scrolling atau saat transisi screen.

#Anatomi Garbage Collector Hermes

Garbage collector bertugas satu hal: membebaskan objek yang sudah tidak direferensikan oleh program. Karena objek JavaScript lahir mati dalam jumlah masif, GC tidak bisa memindai semuanya setiap kali — ia harus pintar. Hermes menggunakan kombinasi tiga strategi: generational, compacting, dan arena.

#Generational GC: Nursery dan Old Generation

Generational GC memanfaatkan fakta empiris yang berlaku di hampir semua runtime: sebagian besar objek mati dalam usia muda. Objek baru lahir di nursery (young generation). Ketika nursery penuh, GC muda hanya memindai nursery, mempromosikan objek yang masih hidup ke old generation, dan membuang sisanya. Old generation tidak pernah disentuh pada siklus ini, sehingga pembersihan "objek sampah muda" jadi sangat cepat.

Strategi ini eksplisit di rancangan Hermes: alokasi objek kecil harus semurah mungkin, dan koleksi nursery harus selesai dalam hitungan milidetik. Harga yang dibayar adalah aturan penguncian (write barrier) agar objek di old generation yang menunjuk ke nursery bisa terlacak.

#Mark-Compact dan Hades

Untuk old generation, Hermes memakai kolektor bertipe mark-compact. Fase mark menelusuri semua objek hidup mulai dari root — global object, stack, dan registry — lalu memberi tanda. Fase compact memadatkan objek hidup ke satu sisi heap sehingga lubang-lubang fragmentasi tertutup.

Pada runtime yang memakai GC Hades, fase mark dikerjakan secara concurrent oleh background thread. Akibatnya pause GC yang terasa oleh aplikasi menjadi jauh lebih pendek dibanding GC stop-the-world biasa. Tentu tidak ada makan siang gratis: kompaksi dan mark concurrent memakan sedikit CPU tambahan dan memori ekstra untuk struktur pelacakan.

#Arena: Alokasi dalam Chunk Besar

Hermes tidak meminta memori ke sistem operasi per-objek. Ia meminta blok besar (chunk) sekali, lalu membagi blok itu menjadi arena tempat objek dialokasikan secara berurutan. Hasilnya: jumlah system call berkurang drastis, alokasi objek menjadi sekadar pointer bump yang sangat cepat, dan seluruh arena bisa dibebaskan massal sekaligus.

Karena itu jangan panik kalau task manager menunjukkan heap yang naik "mendadak". Kemungkinan besar itu bukan kebocoran — itu Hermes mengambil chunk di muka untuk dipakai bertahap.

#Mengintip Memori dengan Runtime Properties

Hermes mengekspos informasi heap lewat HermesInternal.getRuntimeProperties(). Panggil dari dalam aplikasi untuk melihat angka langsung:

cek-runtime-props.js

const props = HermesInternal.getRuntimeProperties();
console.log("UsedBytes:", props.UsedBytes);
console.log("HeapSize:", props.HeapSize);
console.log("BytecodePages:", props.BytecodePages);
console.log("ExternalBytes:", props.ExternalBytes);

UsedBytes memberi tahu berapa byte yang benar-benar dipakai objek, HeapSize ukuran heap yang sudah di-commit, dan ExternalBytes memori yang dipinjam untuk buffer eksternal seperti string besar atau ArrayBuffer. Selisih antara keduanya adalah ruang yang menunggu GC. Untuk eksperimen, kalian juga bisa memaksa koleksi dengan HermesInternal.gc() sebelum mengambil angka, supaya pengukuran dimulai dari kondisi bersih.

#Benchmarking Memory di Aplikasi React Native

Pengukuran lewat HermesInternal hanya menceritakan heap JavaScript. Untuk gambaran utuh, kalian perlu melihat proses aplikasi dari sisi sistem. Di Android, alat paling cepat adalah dumpsys:

adb shell dumpsys meminfo com.example.belajarhermes | grep -E "Native Heap|Java Heap|Total"

Keluaran dumpsys memisahkan memori ke dalam kategori: Native Heap menampung memori yang dipakai kode C/C++ (termasuk Hermes runtime dan bytecode), sedangkan Java Heap dipakai ART dan objek Java. Total keduanya adalah konsumsi nyata aplikasi di mata OS.

Metode yang lebih teliti adalah profiling berjalan:

• Catat baseline dalam kondisi idle setelah aplikasi stabil.
• Jalankan skenario yang ingin diuji — buka satu screen, scroll panjang, tutup screen.
• Ukur lagi, lalu bandingkan. Kenaikan yang tidak pernah turun setelah screen ditutup adalah kandidat kebocoran.

Selain itu, tab Memory di Chrome DevTools Hermes bisa menghasilkan heap snapshot untuk JS heap. Simpan snapshot sebelum dan sesudah sebuah aksi, lalu bandingkan dominator-nya untuk menemukan objek yang tertahan. Lakukan pengukuran di perangkat fisik, bukan emulator — angka emulator sering jauh dari realita perangkat pengguna.

#Praktik Terbaik Meminimalkan Memory Churn

Memory churn adalah fenomena alokasi dan pembebasan objek yang terjadi terlalu sering. Churn yang tinggi membuat GC berputar terus-menerus dan memboroskan CPU. Pola kunci untuk menekannya adalah menggunakan ulang objek yang sudah ada:

object-pool.js

const tokenPool = [];
 
function acquireToken() {
  return tokenPool.pop() || { index: 0, used: false };
}
 
function releaseToken(token) {
  token.used = false;
  tokenPool.push(token);
}

Saat sebuah token dipakai, kalian mengembalikannya ke pool alih-alih membiarkannya mati lalu membuat baru. Ini pola klasik object pooling yang sangat efektif di hot path seperti list rendering atau parsing data berulang. Beberapa kebiasaan lain yang perlu dibangun:

• Jangan alokasikan di dalam hot path. Objek yang dibuat di dalam loop atau fungsi render yang dipanggil ribuan kali akan menekan nursery.
• Hindari menaruh payload API raksasa langsung ke state. Ekstrak hanya field yang dipakai komponen.
• Waspadai closure yang menahan objek besar. Closure yang lama hidup bisa membuat objek "berat" bertahan lebih lama dari yang dibutuhkan.
• Gunakan Object.freeze untuk data yang memang immutable. Ini membantu engine menebak bentuk objek dan mengurangi alokasi tak terduga.
• Ukur dalam kondisi idle. Angka memori saat animasi berjalan hampir selalu menyesatkan.

#Penutup

Kalian sekarang mengenal otak pengelolaan memori Hermes: nursery yang menampung objek muda, mark-compact untuk old generation yang memerangi fragmentasi, Hades yang menggeser kerja GC ke background thread, dan arena yang membuat alokasi menjadi murah. Kalian juga sudah tahu cara mengukur dengan HermesInternal.getRuntimeProperties(), adb shell dumpsys meminfo, dan heap snapshot, plus pola kode untuk menekan memory churn.

Inti yang harus dibawa pulang:

• Hermes memakai generational GC: objek muda mati di nursery, survivor naik ke old generation.
• Mark-compact memadatkan heap untuk menutup fragmentasi; Hades membuatnya concurrent dan minim pause.
• Alokasi Hermes berbasis arena di dalam chunk besar, bukan per-objek — kenaikan heap mendadak belum tentu kebocoran.
• Ukur memori dengan HermesInternal.getRuntimeProperties(), dumpsys, dan heap snapshot sebelum mengubah apa pun.
• Kurangi memory churn dengan object pooling dan menghindari alokasi di hot path.

Di episode 7 berikutnya kita masuk ke sisi operasional yang menyenangkan: debugging dan profiling. Kalian akan menghubungkan Hermes ke Chrome DevTools dan Flipper, memprofil eksekusi JavaScript, mengambil heap snapshot, dan belajar mengenali performance pitfall seperti re-renders, large objects, dan sync loops. Sampai jumpa!