Meta, tingkatkan investasi baru pada jemalloc dan perkuat kolaborasi open source

• jemalloc, allocator memori berperforma tinggi, telah menjadi komponen fondasi yang berperan sebagai infrastruktur inti dalam stack software Meta bersama kernel Linux dan compiler
• Dalam beberapa tahun terakhir, pengembangan jemalloc perlahan menjauh dari prinsip-prinsip rekayasa inti yang sebelumnya memandunya, sehingga utang teknis menumpuk dan laju kemajuan melambat
• Dengan menerima masukan komunitas dan melalui diskusi dengan para kontributor termasuk pendiri proyek Jason Evans, repositori open source asli diaktifkan kembali (unarchived)
• Ke depan, fokus akan diarahkan pada penanganan utang teknis, peningkatan Huge-Page allocator, peningkatan efisiensi memori, dan optimasi AArch64
• Meta menegaskan kembali stewardship jangka panjang untuk jemalloc dan beralih ke arah pengembangan proyek melalui kolaborasi dengan komunitas

---

Posisi dan pentingnya jemalloc

• jemalloc adalah allocator memori berperforma tinggi, komponen yang secara konsisten memberikan leverage tinggi dalam stack software Meta
• jemalloc terus beradaptasi dengan perubahan hardware dan software di lapisan atas, serta berkontribusi pada stabilitas dan performa infrastruktur Meta bersama kernel Linux dan compiler

Penyimpangan dari prinsip dan refleksi

• Komponen software fondasi membutuhkan tingkat ketelitian tertinggi dalam menyeimbangkan pragmatisme dan prinsip
• Karena leverage tinggi yang diberikan jemalloc, selalu ada godaan untuk mengejar keuntungan jangka pendek, dan untuk menolaknya dibutuhkan disiplin diri organisasi yang kuat
• Dalam beberapa tahun terakhir terjadi penyimpangan bertahap dari prinsip-prinsip rekayasa inti yang memandu pengembangan jemalloc
• Beberapa keputusan memberi manfaat langsung, tetapi utang teknis yang dihasilkan justru menghambat kemajuan
• Masukan komunitas diterima dengan serius, dan dilakukan pertemuan dengan anggota komunitas termasuk pendiri proyek Jason Evans
• Ada refleksi mendalam tentang dampak stewardship terhadap kesehatan jangka panjang jemalloc, sekaligus berbagi perubahan pendekatan
• Pekerjaan untuk menghapus utang teknis dan membangun ulang roadmap jangka panjang bagi jemalloc telah dimulai

Babak baru: repositori tidak lagi diarsipkan dan rencana ke depan

• Hasil dialog dengan komunitas membuat repositori open source jemalloc asli diaktifkan kembali (unarchived)
• Meta dapat terus menjalankan peran sebagai steward proyek, dengan fokus pada pengurangan beban pemeliharaan dan modernisasi codebase
  • Penanganan utang teknis: menjaga agar tetap efisien, andal, dan mudah digunakan bagi semua pengguna melalui refactoring dan perbaikan
  • Huge-Page allocator (HPA): memanfaatkan Transparent Hugepages (THP) dengan lebih baik untuk meningkatkan efisiensi CPU
  • Efisiensi memori: mengoptimalkan efisiensi memori melalui perbaikan mekanisme packing, caching, dan purging
  • Optimasi AArch64: memastikan performa yang baik secara default pada platform ARM64

Memperkuat kolaborasi dengan komunitas

• Meta menekankan membangun kepercayaan melalui tindakan dan menargetkan perkembangan jemalloc yang sehat
• Meta menyambut masukan dan partisipasi dari komunitas, serta berharap dapat membangun masa depan jemalloc bersama
• Akan mendorong kolaborasi dan perkembangan yang berkelanjutan di dalam ekosistem open source

[GN⁺]

Komentar Hacker News

• Saat masih bekerja di Facebook, saya pernah memelihara patch kernel untuk memperbaiki mekanisme purging di jemalloc
  Patch itu tidak populer di komunitas kernel maupun keamanan, tetapi cukup efisien dalam benchmark
  Masalahnya, saat memori dialokasikan ulang ke thread lain, terjadi zeroing yang memengaruhi lokalitas cache dan performa
  Itu sebenarnya tindakan yang tidak perlu saat memori didaur ulang dalam domain keamanan yang sama, tetapi sulit mencapai kesepakatan tentang sejauh mana ‘domain keamanan’ harus didefinisikan
  Diskusi terkait ada di milis Linux Kernel

  • Saya masih terkejut patch itu masih disebut-sebut
    Di HHVM kami melakukan benchmark yang luas sebelum dan sesudah patch itu diterapkan, tetapi di level sistem tidak ada perbedaan yang signifikan secara statistik
    Mungkin ada perbaikan di beberapa microbenchmark, tetapi karena tidak memengaruhi performa sistem secara keseluruhan, patch itu dikeluarkan dari kernel
  • Saya penasaran metrik(metric) apa yang sebenarnya membaik
  • Rasanya berbahaya kalau menganggap kebocoran isi memori antarproses itu tidak masalah hanya karena masih berada dalam cgroup yang sama

• Baru-baru ini saya memakai mimalloc dari Microsoft lewat LD_PRELOAD untuk memanfaatkan huge page 1GB
  Saya mendapat peningkatan performa sekitar 20% pada program yang intensif memori
  Agak terasa aneh meningkatkan performa di Linux dengan memakai library open source dari MS
  Saya merasa ranah malloc butuh lebih banyak persaingan

  • Saya sudah menguji beberapa allocator, dan tcmalloc terbaru memberi hasil terbaik baik dari sisi waktu maupun memori
    Aplikasi-aplikasinya ditulis dalam Rust, dan sebagian besar ditautkan secara statis
    Misalnya pada app1, dibanding glibc, tcmalloc mengurangi RSS 35% dan memangkas waktu proses 30%
    Seluruh hasil diuji berdasarkan repositori tcmalloc
  • Dulu ada banyak iklan custom memory allocator di majalah seperti Dr. Dobbs atau BYTE
    Bahkan Turbo Pascal menyediakan API untuk mendefinisikan memory allocator sendiri
    Pada akhirnya, pendekatan “one size fits all” memang sudah lama punya keterbatasan
  • Salah satu kelebihan bahasa GC adalah biaya alokasi/dealokasi yang terikat jadi satu, sehingga lebih jelas terlihat saat profiling
  • Dulu saya terkesan dengan konsep memory pool di Apache Portable Runtime
    Untuk tiap request dibuat satu pool, lalu saat request selesai seluruhnya dibebaskan sekaligus
    Saya rasa malloc masih punya banyak ruang untuk berevolusi ke arah seperti ini
  • Dalam beberapa kasus, memetakan huge page dengan mmap secara langsung lebih efisien daripada malloc
    Jika pola alokasinya sederhana, hasilnya bahkan bisa lebih baik daripada malloc pihak ketiga
    Banyak orang menganggap malloc seperti kotak hitam ajaib, padahal sebenarnya tidak sehebat itu

• Tim kami bermigrasi dari glibc malloc ke jemalloc dua tahun lalu
  Penggunaan memori pada layanan Python turun 15~20%
  Namun di lingkungan container, pengaturan oversize_threshold sangat penting — kalau salah setel bisa memicu OOM
  Saya penasaran apakah ada benchmark yang membandingkan jemalloc dan mimalloc pada layanan yang berjalan lama

• Sebagai bacaan terkait, saya merekomendasikan Jemalloc Postmortem dan
  Jemalloc Repositories Are Archived

• Saya penasaran apakah perubahan kali ini ada hubungannya dengan kelangkaan memori global
  Bisa saja hitungannya menjadi seperti “mengganti memory allocator menghemat jutaan dolar per tahun”

  • Facebook sudah mengejar pengurangan biaya lewat mikro-optimalisasi seperti ini sejak 10 tahun lalu
    Peningkatan efisiensi 0.1% saja bisa menghemat 100 ribu dolar per bulan
    Sumber penghematan utamanya adalah biaya pendinginan(HVAC) dan berkurangnya pembelian server
    Sekarang penghematan memori juga jadi isu besar, tetapi dulu belum begitu
  • Bukan cuma soal biaya, peningkatan efisiensi juga penting untuk mengimbangi keterlambatan pasokan memori
  • Di Meta, mencari penghematan bernilai jutaan dolar adalah hal yang biasa
    Kalau berdampak ke ribuan server, perbaikan kecil pun akan terlihat besar angkanya
    Budaya perbaikan terukur secara kuantitatif seperti ini sudah mengakar
  • Mengingat reputasi perusahaan itu, mungkin ada pertimbangan yang lebih kompleks daripada sekadar kekurangan memori
  • Ini memang saat ketika efisiensi memori server, listrik, dan LLM makin penting
    Lebih cepat 10% saja bisa memberi keunggulan dalam persaingan LLM
    Insentif untuk meningkatkan performa sangat besar

• Saat mengerjakan pemrograman level rendah di Australia, saya terkena PHK
  Saya sangat suka memecahkan masalah seperti ini, tetapi pasar lokal kebanyakan hanya seputar React CRUD, jadi cukup disayangkan

  • Kami sedang merekrut di AU untuk pekerjaan terkait pemrosesan data level rendah. Tautannya ada di bio
  • Saya juga di Australia dan sempat berpikir sama karena hanya mengerjakan React CRUD
  • Jika Anda mencari kerja remote, halaman lowongan Igalia mungkin menarik
  • Perusahaan HFT (IMC trading) juga banyak mengerjakan optimisasi level rendah seperti ini, dan saat ini sedang merekrut di Australia
  • SIG juga membuka posisi terkait di Sydney: SIG Careers

• Dalam proyek startup yang didanai World Bank, kami pernah menerapkan Ruby + jemalloc ke produksi
  Kecepatan dan efisiensi memorinya meningkat jelas sehingga biaya AWS turun cukup besar
  Itu terjadi 8 tahun lalu, jadi saya heran mengapa jemalloc masih belum menjadi standar

  • Kebanyakan hanya karena kurangnya informasi atau inersia
    Mengubah sistem yang sudah berjalan memang tidak mudah, bahkan jika manfaatnya jelas

• Ada juga kasus menggunakan jemalloc untuk melacak penyebab kebocoran memori
  Lihat artikel blog teknis GOV.UK

• Meta telah menggabungkan banyak pekerjaan yang sebelumnya dikerjakan di fork internal mereka
  Bisa dilihat di PR #2863

• Saya penasaran apakah ada materi yang merangkum linimasa atau sejarah jemalloc
  Ini proyek open source, jadi saya bertanya-tanya kenapa Meta memegang kendali utamanya

  • Pendiri Jason Evans merangkum seluruh perjalanannya tahun lalu
    Lihat blog Jemalloc Postmortem
  • Jika melihat commit 5 tahun terakhir, 4 dari 6 kontributor teratas adalah karyawan Meta
    Dua sisanya juga mungkin bekerja di Meta secara tidak terbuka