Belajar Hermes JS Engine - Advanced Memory & GC Tuning

#Pendahuluan

Episode 16 membuka kap mesin compiler. Episode 17 membuka pipa memori. GC Hermes bekerja di belakang layar: mengumpulkan sampah, mengompaksi heap, dan kadang menghentikan eksekusi sesaat. Bagi aplikasi yang berjalan di perangkat dengan RAM pas-pasan, perbedaan konfigurasi GC bisa berarti hidup atau mati secara performa.

Roadmap episode ini: benchmarking heap behavior dan GC pause time, konfigurasi GC untuk low-memory devices, lalu profiling memory leaks dan fragmentation.

#Model Memori dan GC Hermes

Ingat kembali fondasi dari episode 6: Hermes memakai generational GC yang memisahkan objek muda dan tua, heap dikelola dalam arena, dan kompaksi menyatukan memori yang terfragmentasi. Semua mekanisme itu dikendalikan oleh satu objek konfigurasi: GCConfig.

Penting juga mengingat sifat Hermes tanpa JIT: tidak ada memori yang dialokasikan untuk kode yang dihasilkan runtime, sehingga profil memori lebih stabil dan bisa diprediksi. Kelebihan inilah yang membuat tuning GC Hermes terasa bersih — jumlah variabel yang harus dikendalikan lebih sedikit.

#Benchmarking Heap Behavior dan GC Pause

Langkah pertama tuning adalah mengukur. Hermes mengekspos statistik runtime lewat getRuntimeProperties(). Beberapa kunci yang relevan untuk memori:

baca-statistik-gc.js

const p = HermesInternal.getRuntimeProperties();
console.log("Heap size", p["kGCHeapSize"]);
console.log("Total pause", p["kGCTotalPauseTime"]);

Baca nilai-nilai ini secara berkala selama skenario benchmark — misalnya scrolling panjang atau render daftar besar — dan catat angka terburuknya. Di Chrome DevTools, sebagaimana episode 7, heap snapshot juga memberi gambaran distribusi objek. Gabungan keduanya menunjukkan apakah heap membengkak, apakah pause GC terasa di UI thread, dan di titik mana masalah terjadi.

Jadikan pengukuran ini rutinitas: catat baseline sebelum mengubah konfigurasi apa pun. Tanpa baseline, setiap perubahan GC hanya bisa dinilai dari perasaan, bukan dari angka yang objektif.

#Mengukur dan Menekan GC Pause Time

GC pause adalah waktu eksekusi JavaScript dihentikan untuk tugas koleksi. Di aplikasi mobile, pause yang panjang terlihat sebagai jank — frame terasa tersendat. Strategi menekannya:

• Kurangi alokasi: setiap objek yang dibuang adalah pekerjaan GC; pola reuse dari episode 15 berlaku langsung.
• Jaga heap dalam batas: heap yang kecil lebih cepat dikumpulkan, tetapi frekuensi GC naik. Ini trade-off yang harus diukur.
• Hindari peak sesaat: pemicu GC sering kali alokasi mendadak; ratakan pekerjaan yang boros memori.

Untuk mengetahui pause aktual, profil siklus alokasi di DevTools dan bandingkan dengan frame time. Kalau pause mulai dominan, saatnya mempertimbangkan batas heap yang lebih ketat.

Satu cara menyisihkan noise: jalankan benchmark yang sama berulang kali dan ambil median, bukan rata-rata. Rata-rata mudah ditarik ke atas oleh satu lonjakan outlier yang bukan berasal dari kode kalian.

#Konfigurasi GC untuk Low-Memory Devices

Untuk perangkat entry-level, batasi heap supaya aplikasi tidak pernah memaksa OS melakukan pengusiran halaman. Di level embedding C++, konfigurasi memakai GCConfig dan RuntimeConfig:

gc-config.cpp

auto gc = hermes::vm::GCConfig::Builder()
    .withInitHeapSize(1 << 20)
    .withMinHeapSize(1 << 20)
    .withMaxHeapSize(1 << 24)
    .build();
 
auto runtimeConfig = hermes::vm::RuntimeConfig::Builder()
    .withGCConfig(gc)
    .build();
 
auto runtime = HermesRuntime::make(runtimeConfig);

Di binary standalone atau saat debugging, batas yang sama bisa dipakai lewat flag baris perintah:

hermes -Xgc-init-heap-size=8M -Xgc-max-heap-size=64M app.hbc

Aturan praktis: maxHeapSize adalah jaring pengaman, bukan target. Kalau aplikasi kalian sering menyentuh batas, GC akan dipaksa bekerja lebih keras. Turunkan alokasi di sisi kode, lalu sesuaikan batas heap mengikuti ukuran alami aplikasi — bukan sebaliknya.

Mulailah dari heap kecil, lalu naikkan sedikit demi sedikit sampai aplikasi stabil. Angka awal hanyalah tebakan sampai diukur; biarkan data yang menentukan batas final.

#Profiling Memory Leaks dan Fragmentation

Leak di JavaScript terlihat dari heap yang naik terus walau sesi sudah idle. Cara memburunya:

• Ambil heap snapshot sebelum dan sesudah skenario berulang, misalnya buka-tutup layar atau mulai-hentikan task.
• Bandingkan retainer objek di kedua snapshot; objek yang tetap hidup padahal sudah tidak dipakai adalah tersangka utama.
• Perhatikan event listener dan closure yang tidak pernah dilepas — keduanya sumber leak klasik di aplikasi React Native.

Pembersihan yang terlupa sering berbentuk seperti ini:

lepas-listener.js

function mount(ticker) {
  const interval = setInterval(tick, 1000);
  return () => clearInterval(interval);
}
 
const stop = mount(ticker);
stop(); // pastikan dipanggil saat screen unmount

Kalau leak sudah teridentifikasi, langkah perbaikannya konsisten: pastikan cleanup dipanggil di setiap jalur keluar, bukan hanya di skenario utama. Closure yang ditahan oleh event emitter adalah contoh umum yang sering luput dari code review.

Fragmentation adalah cerita lain: heap yang kosong tetapi tersebar sehingga alokasi besar gagal. GC Hermes menangani kompaksi secara periodik, jadi indikatornya adalah alokasi yang menolak meski total memori masih ada. Dalam kasus ini, periksa apakah ada objek raksasa yang dialokasikan berulang, misalnya buffer atau canvas besar, dan pertimbangkan memakainya ulang.

#Penutup

Memori Hermes bisa dikendalikan: ukur dengan statistik runtime dan heap snapshot, kendalikan GC pause dengan mengurangi alokasi, batasi heap untuk perangkat low-memory, dan buru leak serta fragmentation dengan membandingkan retainer antar snapshot. Tuning yang baik selalu dimulai dari data, bukan dugaan.

Inti yang harus dibawa pulang:

• Baca statistik GC lewat getRuntimeProperties() dan amati tren heap, bukan angka absolut.
• GC pause terasa sebagai jank; kurangi alokasi dan ratakan peak untuk menekannya.
• maxHeapSize adalah jaring pengaman, bukan target; sesuaikan dengan ukuran alami aplikasi.
• Leak diburu dengan membandingkan heap snapshot dan retainer sebelum-sesudah skenario.
• Fragmentation terdeteksi dari alokasi besar yang gagal walau total memori masih tersedia.

Di episode 18 kita menutup Fase 5: Debugging Native Integration — debugging jembatan JS-native di React Native, melihat internal calls dan native module boundary, serta menangani crash reporting dan native stack traces. Sampai jumpa!