CPU, GPU, Memori, dan arsitektur multiproses
Dalam seri blog yang terdiri dari 4 bagian ini, kita akan membahas bagian dalam browser Chrome mulai dari arsitektur tingkat tinggi hingga detail pipeline rendering. Jika Anda ingin tahu cara browser mengubah kode menjadi situs yang berfungsi, atau tidak yakin mengapa teknik tertentu disarankan untuk meningkatkan performa, rangkaian ini cocok untuk Anda.
Sebagai bagian 1 dari seri ini, kita akan melihat terminologi komputasi inti dan arsitektur multiproses Chrome.
Inti dari komputer ini adalah CPU dan GPU
Untuk memahami lingkungan yang dijalankan oleh browser, kita perlu memahami beberapa bagian komputer dan apa yang dilakukannya.
CPU
Pertama adalah Central Cergunaan Cnit - atau C. CPU dapat dianggap sebagai otak komputer Anda. Inti CPU, yang digambarkan sebagai pekerja kantoran, dapat menangani berbagai tugas satu per satu begitu masuk. Teknologi ini dapat menangani semuanya mulai dari matematika hingga seni sekaligus mengetahui cara membalas panggilan pelanggan. Di masa lalu, sebagian besar CPU merupakan {i>chip<i} tunggal. Inti seperti CPU lain yang berada dalam {i>chip<i} yang sama. Di hardware modern, Anda sering mendapatkan lebih dari satu core, sehingga memberikan lebih banyak daya komputasi ke ponsel dan laptop Anda.
GPU
Graphics Menggunakan Unit - atau GPU adalah bagian lain dari komputer. Tidak seperti CPU, GPU mahir menangani tugas sederhana, tetapi di beberapa core sekaligus. Seperti namanya, alat ini pertama kali dikembangkan untuk menangani grafis. Inilah sebabnya mengapa dalam konteks grafis "menggunakan GPU" atau "didukung GPU" dikaitkan dengan rendering cepat dan interaksi yang lancar. Dalam beberapa tahun terakhir, dengan komputasi yang dipercepat GPU, semakin banyak komputasi yang dapat dilakukan dengan GPU saja.
Saat Anda memulai aplikasi di komputer atau ponsel, CPU dan GPUlah yang menggerakkan aplikasi. Biasanya, aplikasi berjalan di CPU dan GPU menggunakan mekanisme yang disediakan oleh Sistem Operasi.
Menjalankan program di Process dan Thread
Konsep lain yang harus dipahami sebelum mendalami arsitektur browser adalah Proses dan Thread. Proses dapat dijelaskan sebagai program eksekusi aplikasi. Thread adalah thread yang berada di dalam proses dan mengeksekusi setiap bagian dari program prosesnya.
Saat Anda memulai aplikasi, sebuah proses akan dibuat. Program ini dapat membuat thread untuk membantunya melakukannya, tetapi hal itu bersifat opsional. Sistem Operasi memberi proses "slab" memori untuk digunakan dan semua status aplikasi disimpan di ruang memori pribadi tersebut. Saat Anda menutup aplikasi, proses juga akan hilang dan Sistem Operasi mengosongkan memori.
Sebuah proses dapat meminta Sistem Operasi untuk memulai proses lain guna menjalankan tugas yang berbeda. Jika hal ini terjadi, berbagai bagian memori akan dialokasikan untuk proses baru. Jika dua proses perlu berbicara, proses tersebut dapat melakukannya dengan menggunakan DerPoses ommunikasi (IPC). Banyak aplikasi dirancang untuk bekerja dengan cara ini sehingga jika proses pekerja tidak responsif, aplikasi dapat dimulai ulang tanpa menghentikan proses lain yang menjalankan bagian aplikasi yang berbeda.
Arsitektur browser
Jadi, bagaimana {i>browser<i} web dibuat menggunakan proses dan thread? Nah, itu bisa jadi satu proses dengan banyak thread berbeda, atau banyak proses yang berbeda dengan beberapa thread yang berkomunikasi melalui IPC.
Hal penting yang perlu diperhatikan di sini adalah bahwa arsitektur yang berbeda ini merupakan detail implementasi. Tidak ada spesifikasi standar tentang bagaimana seseorang dapat membuat sebuah {i>browser<i} web. Pendekatan satu browser mungkin sangat berbeda dari yang lain.
Untuk seri blog ini, kami menggunakan arsitektur terbaru Chrome, yang dijelaskan dalam Gambar 8.
Di bagian atas terdapat proses browser yang berkoordinasi dengan proses lain yang menangani berbagai bagian aplikasi. Untuk proses perender, beberapa proses dibuat dan ditetapkan ke setiap tab. Hingga baru-baru ini, Chrome memberikan proses kepada setiap tab sebisa mungkin; sekarang Chrome mencoba memberikan prosesnya sendiri untuk setiap situs, termasuk iframe (lihat Isolasi Situs).
Proses mana yang mengontrol apa?
Tabel berikut menjelaskan setiap proses Chrome dan hal yang dikontrolnya:
| Proses dan Apa yang dikontrolnya | |
|---|---|
| Browser |
Mengontrol bagian "chrome" dari aplikasi termasuk kolom URL, bookmark, tombol kembali, dan
maju. Juga menangani bagian yang tidak terlihat dan memiliki hak istimewa dari browser web, seperti permintaan jaringan dan akses file. |
| Perender | Mengontrol apa pun di dalam tab tempat situs ditampilkan. |
| Pengaya | Mengontrol plugin apa pun yang digunakan oleh situs, misalnya flash. |
| GPU | Menangani tugas GPU secara terpisah dari proses lain. Fungsi ini dipisahkan ke dalam proses yang berbeda karena GPU menangani permintaan dari beberapa aplikasi dan menggambarnya di platform yang sama. |
Bahkan ada lebih banyak proses seperti proses Ekstensi dan proses utilitas. Jika Anda ingin melihat berapa banyak proses yang berjalan di Chrome, klik ikon menu opsi di pojok kanan atas, pilih More Tools, lalu pilih Task Manager. Tindakan ini akan membuka jendela berisi daftar proses yang sedang berjalan dan jumlah CPU/Memori yang digunakan.
Manfaat arsitektur multiproses di Chrome
Sebelumnya, saya menyebutkan bahwa Chrome menggunakan beberapa proses perender. Dalam kasus paling sederhana, Anda dapat menganggap setiap tab memiliki proses perendernya sendiri. Misalkan Anda memiliki 3 tab yang terbuka dan setiap tab dijalankan oleh proses perender independen.
Jika satu tab tidak responsif, Anda dapat menutup tab yang tidak responsif dan melanjutkan sambil menjaga tab lainnya tetap aktif. Jika semua tab berjalan dalam satu proses, saat satu tab menjadi tidak responsif, semua tab tidak akan responsif. Sayang sekali.
Manfaat lain memisahkan pekerjaan browser ke dalam banyak proses adalah keamanan dan sandbox. Karena sistem operasi memberikan cara untuk membatasi hak istimewa proses, browser dapat melakukan sandbox proses tertentu dari fitur tertentu. Misalnya, browser Chrome membatasi akses file arbitrer untuk proses yang menangani input pengguna arbitrer seperti proses perender.
Karena memiliki ruang memori pribadinya sendiri, proses sering kali berisi salinan infrastruktur umum (seperti V8 yang merupakan mesin JavaScript Chrome). Ini berarti penggunaan memori yang lebih banyak karena tidak dapat dibagikan seperti jika berada dalam thread dalam proses yang sama. Untuk menghemat memori, Chrome membatasi jumlah proses yang dapat dijalankannya. Batasnya bervariasi, bergantung pada banyaknya memori dan daya CPU yang dimiliki perangkat, tetapi saat Chrome mencapai batas, Chrome akan mulai menjalankan beberapa tab dari situs yang sama dalam satu proses.
Menghemat lebih banyak memori - Layanan di Chrome
Pendekatan yang sama diterapkan pada proses browser. Chrome sedang melakukan perubahan arsitektur untuk menjalankan setiap bagian program browser sebagai layanan sehingga memungkinkan untuk dipecah ke dalam berbagai proses atau digabungkan menjadi satu.
Ide umumnya adalah saat berjalan dengan hardware canggih, Chrome dapat membagi setiap layanan menjadi berbagai proses agar lebih stabil, namun jika dijalankan di perangkat dengan resource terbatas, Chrome akan menggabungkan layanan ke dalam satu proses sehingga menghemat jejak memori. Pendekatan serupa dalam menggabungkan proses untuk lebih sedikit penggunaan memori telah digunakan di platform seperti Android sebelum perubahan ini.
Proses perender per frame - Isolasi Situs
Isolasi Situs adalah fitur yang baru diperkenalkan di Chrome yang menjalankan proses perender terpisah untuk setiap iframe lintas situs. Kita telah membahas satu proses perender per model tab yang memungkinkan iframe lintas situs berjalan dalam satu proses perender dengan berbagi ruang memori antar-situs yang berbeda. Menjalankan a.com dan b.com dalam proses perender yang sama mungkin tampak tidak masalah. Kebijakan Asal yang Sama adalah model keamanan inti web; model ini memastikan satu situs tidak dapat mengakses data dari situs lain tanpa izin. Menghindari kebijakan ini adalah tujuan utama serangan keamanan. Isolasi proses adalah cara paling efektif untuk memisahkan situs. Dengan Meltdown dan Spectre, semakin jelas bahwa kami perlu memisahkan situs menggunakan proses. Dengan Isolasi Situs yang diaktifkan di desktop secara default sejak Chrome 67, setiap iframe lintas situs di tab akan mendapatkan proses perender yang terpisah.
Mengaktifkan Isolasi Situs telah menjadi upaya engineering selama bertahun-tahun. Isolasi Situs tidak semudah menetapkan proses perender yang berbeda; isolasi situs pada dasarnya mengubah cara iframe berkomunikasi dengan satu sama lain. Jika membuka devtools di halaman dengan iframe yang berjalan pada berbagai proses, devtools harus mengimplementasikan pekerjaan di balik layar agar terlihat lancar. Bahkan menjalankan Ctrl+F sederhana untuk menemukan kata dalam halaman berarti melakukan penelusuran di berbagai proses perender. Anda dapat melihat alasan engineer browser membahas rilis Isolasi Situs sebagai pencapaian utama.
Rangkuman
Dalam postingan ini, kita telah membahas tampilan tingkat tinggi arsitektur browser dan membahas manfaat arsitektur multiproses. Kita juga telah membahas Layanan dan Isolasi Situs di Chrome yang sangat terkait dengan arsitektur multi-proses. Dalam postingan berikutnya, kita akan mulai membahas apa yang terjadi antara proses dan thread ini untuk menampilkan situs.
Apakah Anda menikmati postingan itu? Jika ada pertanyaan atau saran untuk postingan mendatang, hubungi Anda di @kosamari di Twitter.