Memory Management

Manajemen Memori

Kita akan menyelami dunia memory management di Go, berfokus pada mekanisme dan strategi yang mendasari garbage collection. Sambil kita menavigasi konsep garbage collection, termasuk evolusinya dalam Go, perbedaan antara alokasi memori stack dan heap, dan teknik-teknik canggih yang digunakan untuk mengelola memori secara efisien, Anda akan memahami cara kerja sistem memory management Go.

kita akan membahas topik utama berikut:

• Garbage collection

• Memory arenas

Di akhir Anda diharapkan mampu mengoptimalkan kode Anda untuk mengurangi penggunaan memori, meminimalkan overhead garbage collection, dan pada akhirnya meningkatkan skalabilitas dan responsivitas aplikasi Anda.

Garbage Collection

Sebelum bahasa-bahasa yang di-garbage collect, kita perlu menangani memory management sendiri. Terlepas dari perhatian terfokus yang dibutuhkan disiplin ini, masalah utama yang terus kita hadapi untuk dihindari adalah memory leak, dangling pointer, dan double free.

Garbage collector di Go memiliki beberapa tugas untuk menghindari kesalahan dan masalah umum: ia melacak alokasi di heap, membebaskan alokasi yang tidak diperlukan, dan menyimpan alokasi yang sedang digunakan. Tugas-tugas ini biasanya disebut dalam dunia akademis sebagai memory inference, atau "Memori mana yang harus saya bebaskan?". Dua strategi utama untuk menangani memory inference adalah tracing dan reference counting.

Go menggunakan tracing garbage collector (disingkat GC), yang berarti GC akan melacak objek yang dapat dijangkau oleh rantai referensi dari objek "root", menganggap sisanya sebagai "sampah", dan mengumpulkannya. Garbage collector Go telah melalui perjalanan panjang optimasi dan pembelajaran. Anda dapat menemukan seluruh jalur menuju keadaan saat ini di blog post dari tim pengembang Go ini: https://go.dev/blog/ismmkeynote.

Dalam blog post ini, tim Go melaporkan perolehan besar. Misalnya, satu siklus garbage collection turun dari 300 ms (Go 1.0) menjadi, yang mengejutkan, 0,5 ms di versi terbaru.

Anda pasti pernah mendengar ini setidaknya sekali di komunitas teknologi: " Garbage collection di Go bersifat otomatis, jadi Anda bisa melupakan memory management." Mempercayai ini seperti berpikir rumah Anda membersihkan dirinya sendiri karena Anda punya Roomba. Di Go, memahami garbage collection bukan hanya sekadar nice-to-have; ini adalah tiket Anda untuk menulis kode yang efisien dan berkinerja tinggi. Jadi, bersiaplah, kita akan menyelami dunia di mana "otomatis" tidak berarti "ajaib".

Bayangkan, jika Anda mau, sebuah tim pengembangan perangkat lunak yang tidak pernah meninjau kode karena, hei, mereka punya linter. Itu mirip dengan bagaimana sebagian orang mendekati garbage collector Go. Ini seperti mempercayakan seluruh kualitas basis kode Anda ke program yang memeriksa whitespace tambahan. Tentu, GC di Go adalah petugas kebersihan kecil yang rapi, tanpa lelah membersihkan kekacauan memori Anda. Tetapi salah memahami modus operandi-nya seperti berpikir linter Anda akan memfaktorkan ulang kode spaghetti Anda menjadi hidangan yang layak.

Untuk membuka jalan menuju pengetahuan yang lebih mendalam tentang GC, pertama, kita perlu memahami dua area memori: stack dan heap.

Alokasi Stack dan Heap

Alokasi stack di Go digunakan untuk variabel yang lifetime-nya dapat diprediksi dan terikat pada panggilan fungsi yang membuatnya. Ini adalah variabel lokal Anda, parameter fungsi, dan nilai kembalian. Stack sangat efisien karena sifatnya yang Last In, First Out (LIFO). Mengalokasikan dan mendealokasikan memori di sini hanyalah masalah memindahkan stack pointer ke atas atau ke bawah. Kesederhanaan ini membuat alokasi stack cepat, tetapi bukan tanpa batasan. Ukuran stack relatif kecil, dan mencoba memasukkan terlalu banyak hal ke dalam stack dapat menyebabkan stack overflow yang ditakuti.

Sebaliknya, alokasi heap adalah untuk variabel yang lifetime-nya kurang dapat diprediksi dan tidak terikat secara ketat pada tempat mereka dibuat. Ini biasanya adalah variabel yang harus hidup di luar scope fungsi tempat mereka dibuat. Heap adalah ruang yang lebih fleksibel dan dinamis, dan variabel di sini dapat diakses secara global. Namun, fleksibilitas ini datang dengan harga. Mengalokasikan memori di heap lebih lambat karena kebutuhan akan pembukuan yang lebih kompleks, dan tanggung jawab mengelola memori ini berada di tangan garbage collector, yang menambah overhead.

Compiler Go melakukan trik rapi yang disebut " escape analysis " (lebih lanjut tentang topik ini di Bab 9, Menganalisis Kinerja) untuk memutuskan apakah suatu variabel harus hidup di stack atau heap. Jika compiler menentukan bahwa lifetime variabel tidak keluar dari fungsi tempat ia berada, maka ia masuk ke stack. Tetapi jika referensi variabel diteruskan atau dikembalikan dari fungsi, maka ia "keluar" ke heap.

Proses pengambilan keputusan otomatis ini adalah keuntungan bagi para pengembang, karena mengoptimalkan penggunaan memori dan kinerja tanpa intervensi manual. Perbedaan antara alokasi stack dan heap memiliki implikasi kinerja yang signifikan. Memori yang dialokasikan di stack cenderung menghasilkan kinerja yang lebih baik karena mekanisme alokasi dan dealokasinya yang mudah.

Memori yang dialokasikan di heap, meskipun diperlukan untuk data yang lebih kompleks dan dinamis, menimbulkan cost kinerja karena overhead garbage collection. Sebagai pengembang Go, memperhatikan bagaimana variabel Anda dialokasikan dapat membantu dalam menulis kode yang lebih efisien. Meskipun Go mengabstraksi sebagian besar kompleksitas memory management, memiliki pemahaman yang baik tentang bagaimana alokasi heap dan stack bekerja dapat sangat memengaruhi kinerja aplikasi Anda.

Sebagai aturan praktis, simpan variabel Anda dalam scope sesempit mungkin, dan berhati-hatilah dengan pointer dan referensi yang dapat menyebabkan alokasi heap yang tidak perlu.

Oke, mari kita masuk ke teknis. Garbage collection Go didasarkan pada algoritma concurrent, tri-color mark-and-sweep. Sekarang, sebelum mata Anda menjadi sayu seperti donat, mari kita uraikan itu.

Algoritma GC

• Concurrent berarti ia berjalan bersamaan dengan program Anda, tidak menghentikan segalanya untuk membersihkan. Ini penting untuk kinerja, terutama dalam sistem real-time di mana jeda untuk housekeeping sama tidak diinginkannya dengan freeze layar pada hari peluncuran.

• Bit tri-color adalah tentang bagaimana GC memandang objek. Anggap saja ini sebagai lampu lalu lintas untuk memori: hijau untuk "digunakan," merah untuk "siap dihapus," dan kuning untuk "mungkin, mungkin tidak."

• Bagian terakhir, mark and sweep, adalah definisi dari dua fase utama proses tersebut. Versi singkat dari ceritanya adalah: selama fase "mark," GC memindai objek Anda, membalik warnanya berdasarkan aksesibilitas. Dalam fase "sweep," ia membuang sampah – objek merah. Proses dua langkah ini membantu dalam mengelola memori secara efisien tanpa mengganggu program Anda yang sedang berjalan. Setelah kita memiliki gambaran besar, kita dapat menjelajahi detail dari kedua fase ini dengan mudah.

Fase Marking

Fase "mark" dibagi menjadi dua bagian. Di bagian awal, GC menghentikan program sebentar (kurang dari 0,3 milidetik) – anggap saja ini sebagai tarikan napas cepat sebelum menyelam di bawah air. Selama jeda ini, yang dikenal sebagai fase stop-the-world (STW), GC mengidentifikasi root set. Root ini pada dasarnya adalah variabel yang dapat diakses langsung dari stack, global, dan lokasi khusus lainnya. Dengan kata lain, ini adalah momen ketika GC akan memulai pencariannya untuk mengidentifikasi apa yang digunakan dan apa yang tidak.

Setelah mengidentifikasi root set, GC melanjutkan ke marking aktual, yang terjadi bersamaan dengan eksekusi program. Di sinilah metafora "tri-color" bersinar. Objek awalnya ditandai "putih," yang berarti nasib mereka belum diputuskan. Saat GC menemukan objek-objek ini dari root, ia menandainya "abu-abu," yang menunjukkan bahwa mereka perlu dieksplorasi lebih lanjut, dan akhirnya mengubahnya menjadi "hitam" setelah diproses sepenuhnya, yang menandakan bahwa mereka sedang digunakan. Sistem kode warna ini memastikan bahwa GC menilai secara komprehensif aksesibilitas setiap objek.

Ada lebih banyak detail penting untuk dijelaskan dalam proses ini. Karena kita ingin membuat sistem berperforma tinggi, kita perlu menguasai pengetahuan GC kita daripada menyimpan hal-hal teoretis.

Selama fase marking, runtime Go dengan sengaja mengalokasikan sekitar 25% dari sumber daya CPU yang tersedia. Alokasi ini adalah keputusan yang diperhitungkan, memastikan bahwa GC cukup efisien untuk menjaga penggunaan memori tetap terkendali tanpa membebani sistem. Ini adalah tindakan penyeimbangan, mirip dengan seorang juggler yang memastikan setiap bola mendapat waktu tayang yang cukup tetapi tidak mendominasi sorotan. Alokasi 25% ini sangat penting untuk menjaga pekerjaan GC tetap stabil dan tidak mengganggu.

Selain alokasi CPU standar, ada ketentuan untuk tambahan 5% CPU untuk digunakan melalui mark assist. Mark assist ini dipicu ketika program membuat alokasi memori selama siklus GC. Jika GC tertinggal, goroutine yang mengalokasikan membantu (atau dalam hal ini, beberapa siklus CPU) untuk membantu dalam proses marking. Tambahan 5% ini dapat dilihat sebagai kekuatan cadangan, dipanggil ketika situasi membutuhkannya, memastikan bahwa GC tetap sejalan dengan rate alokasi memori.

Sweep

Beralih ke fase sweep, di sinilah dealokasi berperan. Setelah fase marking mengidentifikasi objek mana yang tidak lagi diperlukan (yang masih ditandai sebagai "putih"), fase sweep memulai proses dealokasi memori ini. Fase ini sangat penting karena di sinilah reklamasi memori aktual terjadi, membebaskan ruang untuk alokasi di masa mendatang. Efisiensi fase ini secara langsung memengaruhi footprint memori aplikasi dan kinerja keseluruhan. Tetapi ini tidak semuanya indah dan menyenangkan.

GC masih dapat menyebabkan masalah kinerja, seperti latency spike, terutama ketika berhadapan dengan heap besar atau aplikasi yang haus memori. Memahami cara mengoptimalkan kode Anda untuk bermain bagus dengan GC adalah sebuah seni. Ini melibatkan penyelaman mendalam ke dalam manajemen pointer, menghindari memory leak, dan terkadang hanya mengetahui kapan harus berkata, "Hei, GC, kamu bisa istirahat; saya bisa menangani ini."

GOGC

Variabel lingkungan GOGC di Go adalah tuning knob dari garbage collector. Ini seperti termostat sistem pemanas rumah Anda, mengontrol seberapa panas atau dingin yang Anda inginkan di ruangan. Dalam konteks Go, GOGC menentukan agresivitas proses garbage collection. Ini menentukan seberapa banyak memori yang baru dialokasikan diizinkan sebelum garbage collector memicu siklus lain. Memahami dan menyesuaikan variabel ini dapat secara signifikan memengaruhi penggunaan memori dan kinerja aplikasi Go Anda.

Nilai default-nya adalah 100, yang berarti GC mencoba untuk menyisakan setidaknya 100% dari memori heap awal yang tersedia setelah siklus GC baru. Menyesuaikan nilai GOGC memungkinkan Anda menyesuaikan garbage collection dengan kebutuhan spesifik aplikasi Anda.

Go env

GOGC adalah variabel lingkungan yang memengaruhi GC, tetapi ini bukan opsi konfigurasi khusus untuk toolchain atau compiler Go.

Menyetel GOGC ke nilai yang lebih rendah, katakanlah 50, berarti GC akan berjalan lebih sering, menjaga ukuran heap lebih kecil tetapi menggunakan lebih banyak waktu CPU. Di sisi lain, menyetelnya lebih tinggi, seperti 200, berarti GC akan berjalan lebih jarang, memungkinkan lebih banyak alokasi memori tetapi berpotensi menyebabkan peningkatan penggunaan memori yang tidak diinginkan.

Variabel GOGC dapat mengambil nilai integer apa pun yang lebih besar dari 0. Menyetelnya ke nilai yang sangat rendah dapat menyebabkan penurunan kinerja karena GC berjalan terlalu sering, seperti petugas kebersihan yang terus-menerus membersihkan hingga menjadi gangguan. Sebaliknya, menyetelnya terlalu tinggi dapat menyebabkan aplikasi Anda menggunakan lebih banyak memori daripada yang diperlukan, yang mungkin tidak ideal di lingkungan dengan keterbatasan memori. Penting untuk menemukan sweet spot yang spesifik untuk karakteristik memori dan kinerja aplikasi Anda.

Ada juga nilai khusus untuk GOGC. Menyetelnya ke off menonaktifkan garbage collection otomatis sepenuhnya. Ini mungkin berguna dalam skenario di mana sifat program yang berumur pendek tidak memerlukan overhead GC. Namun, dengan kekuatan besar datang tanggung jawab besar; menonaktifkan GC dapat menyebabkan pertumbuhan memori yang tidak terkendali. Ini sedikit seperti mematikan termostat otomatis rumah Anda – bisa bermanfaat dalam keadaan yang tepat tetapi membutuhkan lebih banyak perhatian untuk mencegah masalah.

Dalam praktiknya, menyetel GOGC adalah masalah memahami profil memori dan persyaratan kinerja aplikasi Anda. Ini membutuhkan eksperimen dan pemantauan yang cermat. Menyesuaikan variabel ini dapat menghasilkan peningkatan kinerja yang signifikan, terutama dalam sistem dengan heap besar atau batasan real-time.

GC Pacer

GC pacer di Go dapat diibaratkan sebagai konduktor orkestra, memastikan setiap bagian masuk pada waktu yang tepat untuk menciptakan simfoni yang harmonis. Tugasnya adalah mengatur waktu siklus garbage collection, menyeimbangkan kebutuhan untuk mereklamasi memori dengan kebutuhan untuk menjaga program tetap berjalan secara efisien. Keputusan pacer didasarkan pada ukuran heap saat ini, rate alokasi, dan tujuan mempertahankan kinerja program.

Peran utama pacer adalah menentukan kapan harus memulai siklus garbage collection baru. Ia melakukan ini dengan memantau rate alokasi memori dan ukuran live heap (diisyaratkan oleh GOGC) – memori yang digunakan yang tidak dapat diklaim kembali. Strategi pacer adalah memicu siklus GC sebelum program mengalokasikan terlalu banyak memori, yang dapat menyebabkan peningkatan latency atau tekanan memori. Ini adalah tindakan pencegahan, mirip dengan mengganti oli di mobil Anda sebelum berubah menjadi masalah yang lebih besar.

Salah satu fitur utama dari GC pacer adalah sifat adaptifnya. Ia terus-menerus menyesuaikan threshold-nya berdasarkan perilaku aplikasi. Jika aplikasi mengalokasikan memori dengan cepat, pacer merespons dengan memicu siklus GC lebih sering untuk mengimbanginya. Sebaliknya, jika rate alokasi aplikasi melambat, pacer akan memungkinkan lebih banyak memori dialokasikan sebelum memulai siklus GC. Kemampuan beradaptasi ini memastikan bahwa perilaku pacer selaras dengan kebutuhan aplikasi saat ini.

Pacer bekerja bersamaan dengan variabel lingkungan GOGC. GOGC menetapkan persentase pertumbuhan heap yang diizinkan sebelum siklus GC dipicu. Pacer menggunakan nilai ini sebagai panduan untuk menentukan threshold-nya.

Efektivitas GC pacer memiliki dampak langsung pada kinerja aplikasi. Pacer yang disetel dengan baik memastikan bahwa garbage collection terjadi dengan lancar, tanpa menyebabkan jeda atau latency spike yang signifikan. Namun, jika threshold pacer tidak selaras dengan baik dengan perilaku aplikasi, itu dapat menyebabkan siklus GC yang berlebihan, yang dapat menurunkan kinerja, atau penundaan pengumpulan, yang dapat meningkatkan penggunaan memori. Ini seperti menemukan kecepatan yang tepat untuk cruise control – terlalu cepat atau terlalu lambat dapat menyebabkan perjalanan yang tidak nyaman.

GC pacer di Go adalah komponen penting yang memastikan efisiensi proses garbage collection. Ini bukan hanya tentang menulis kode; ini tentang memahami lingkungan tempat kode Anda berjalan, dan GC pacer adalah bagian penting dari lingkungan itu.

GODEBUG

Variabel lingkungan GODEBUG di Go adalah tool yang ampuh untuk para pengembang, yang menawarkan wawasan tentang cara kerja runtime Go. Secara khusus, pengaturan GODEBUG=gctrace=1 sering digunakan untuk mendapatkan informasi terperinci tentang proses garbage collection. Mari kita jelajahi ini secara mendalam.

GODEBUG di Go seperti toolkit diagnostik untuk mobil Anda. Sama seperti Anda mungkin mencolokkan tool diagnostik untuk memahami apa yang terjadi di bawah kap mobil Anda, GODEBUG memberikan wawasan tentang runtime Go. Di antara berbagai kemampuannya, salah satu yang paling banyak digunakan adalah gctrace. Ketika diatur ke 1 (GODEBUG=gctrace=1), ia mengaktifkan pelacakan aktivitas GC, menawarkan jendela tentang bagaimana dan kapan garbage collection terjadi di aplikasi Go Anda.

Mengaktifkan gctrace ke 1 menghasilkan informasi terperinci untuk setiap siklus GC, termasuk waktu dimulainya, durasinya, ukuran heap sebelum dan sesudah pengumpulan, dan jumlah memori yang diklaim kembali. Data ini sangat berharga untuk memahami dampak GC pada kinerja aplikasi Anda. Ini seperti mendapatkan komentar play-by-play tentang bagaimana GC mengelola memori, yang bisa sangat penting untuk tuning kinerja.

Output dari gctrace=1 bisa sangat padat dan mungkin tampak menakutkan pada awalnya. Ini mencakup beberapa metrik, seperti waktu STW, yang menunjukkan berapa lama aplikasi Anda berhenti selama GC. Detail lainnya termasuk jumlah goroutine yang berjalan, ukuran heap, dan jumlah siklus GC. Membaca output ini seperti memecahkan kode peta harta karun; setelah Anda memahami simbol dan angka, itu mengungkapkan informasi berharga tentang di mana kinerja aplikasi Anda dapat ditingkatkan. Ambil output ini sebagai contoh:

gc 1 @0.019s 2%: 0.015+2.5+0.003 ms clock, 0.061+0.5/2

Tentu, ini dia kelanjutan artikel tentang Memory Management dalam Bahasa Indonesia, berdasarkan teks yang Anda berikan:

---

ms (stw=0.015 aging=25% gc=23% ncpu=12)

Dalam output ini, gc 1 menunjukkan bahwa ini adalah siklus garbage collection pertama. @0.019s berarti siklus dimulai 0,019 detik setelah program dimulai. 2% menunjukkan persentase waktu CPU yang dihabiskan untuk garbage collection. Angka-angka setelah itu memberikan breakdown waktu yang dihabiskan dalam berbagai fase garbage collection.

Memahami output ini memungkinkan pengembang untuk mengidentifikasi bottleneck terkait memori dan mengoptimalkan kode mereka untuk mengurangi tekanan pada garbage collector.

Singkatnya, GODEBUG dengan gctrace=1 adalah tool yang ampuh untuk memantau aktivitas garbage collection dalam aplikasi Go. Ini memberikan wawasan terperinci tentang bagaimana memori dikelola, membantu pengembang dalam membuat keputusan yang tepat tentang tuning kinerja dan memory management. Ini seperti memiliki dashboard di mobil Anda yang memberi tahu Anda segalanya tentang kesehatan dan kinerja mesin Anda.

Memory Arenas

Memory arena adalah wilayah memori yang besar dan contiguous yang dialokasikan sekaligus. Semua alokasi untuk jenis objek tertentu kemudian dialokasikan dari arena ini. Setelah semua objek di arena tidak lagi digunakan, seluruh arena dapat dibebaskan sekaligus, yang jauh lebih efisien daripada membebaskan setiap objek satu per satu.

Go tidak memiliki memory arena sebagai fitur bawaan. Namun, ada package pihak ketiga yang dapat membantu Anda mengimplementasikannya, seperti github.com/andybalholm/arena.

Memory arena sering digunakan dalam situasi di mana sejumlah besar objek kecil dibuat dan dihancurkan dengan cepat, seperti dalam penguraian atau pemrosesan grafik. Dalam skenario ini, overhead dari alokasi dan dealokasi memori individu dapat menjadi signifikan. Memory arena menawarkan cara untuk mengurangi overhead ini dengan mengelola alokasi memori dalam jumlah besar.

Ada beberapa trade-off yang perlu dipertimbangkan saat menggunakan memory arena. Salah satunya adalah semua objek di arena harus memiliki lifetime yang sama. Jika beberapa objek di arena perlu hidup lebih lama dari yang lain, maka arena tidak dapat dibebaskan hingga semua objek telah dihancurkan. Ini dapat menyebabkan peningkatan penggunaan memori. Trade-off lainnya adalah bahwa memory arena dapat lebih kompleks untuk diimplementasikan daripada menggunakan alokasi memori reguler.

Berikut adalah beberapa panduan untuk membantu Anda memutuskan apakah akan menggunakan memory arena:

• Apakah Anda memiliki sejumlah besar alokasi?

Jika Anda tidak memiliki data, Anda menebak:

• Apakah saya memiliki beberapa alokasi atau hanya sedikit?

Jika Anda tidak memiliki banyak alokasi, program Anda akan menggunakan lebih banyak memori dengan memperkenalkan arena. Anda dapat menggunakan aturan praktis bahwa arena berukuran 8 MB.

• Apakah memiliki struktur kecil yang sama?

Mungkin Anda mencari tool yang salah. Pertimbangkan untuk menggunakan sync.Pool.

• Apakah ini hot path dari program saya?

Ini mungkin merupakan optimasi prematur. Bereksperimenlah dengan beberapa kombinasi GC dan GOMEMLIMIT sebelum mempertimbangkan memory arena.

Saatnya untuk membungkus pengetahuan kita tentang memory management.

Ringkasan

Kita telah menjelajahi GC, perbedaan antara alokasi stack dan heap, dan cara untuk mengoptimalkan penggunaan memori untuk kinerja yang lebih baik. Juga, kita telah mengungkap evolusi garbage collector Go dan metodenya, termasuk topik lanjutan seperti algoritmanya (tri-color/concurrent/mark and sweep). Kita juga telah membahas pendekatan praktis termasuk menggunakan variabel lingkungan seperti GOGC untuk menyempurnakan garbage collection dan menggunakan teknik seperti memory ballast dan GOMEMLIMIT untuk membantu GC mengelola memori program.

Selama materi ini, Anda mungkin bertanya pada diri sendiri: Berapa banyak kinerja yang kita peroleh, utak-atik, dan tweaking parameter GC dan runtime, dan menggabungkan teknik-teknik ini?

Jawabannya sederhana: Kinerja bukanlah permainan tebak-tebakan. Kita harus mengukurnya.