Perangkat lunak berjalan di OS dengan premis yang sangat sederhana - mereka membutuhkan memori. OS perangkat menyediakannya dalam bentuk RAM. Jumlah memori yang diperlukan dapat bervariasi - beberapa perangkat lunak membutuhkan memori yang sangat besar, beberapa membutuhkan memori yang tidak seberapa. Sebagian besar (jika tidak semua) pengguna menjalankan beberapa aplikasi pada OS secara bersamaan, dan mengingat bahwa memori mahal (dan ukuran perangkat terbatas), jumlah memori yang tersedia selalu terbatas. Jadi mengingat bahwa semua perangkat lunak memerlukan sejumlah RAM, dan semuanya dapat dijalankan pada waktu yang sama, OS harus menangani dua hal:
- Bahwa perangkat lunak selalu berjalan sampai pengguna membatalkannya, yaitu tidak boleh otomatis dibatalkan karena OS kehabisan memori.
- Aktivitas di atas, dengan tetap mempertahankan kinerja yang terhormat untuk perangkat lunak yang sedang berjalan.
Sekarang pertanyaan utamanya adalah bagaimana memori dikelola. Apa sebenarnya yang mengatur di mana dalam memori akan data milik perangkat lunak tertentu berada?
Solusi yang memungkinkan 1 : Biarkan setiap perangkat lunak menentukan secara eksplisit alamat memori yang akan mereka gunakan di perangkat. Misalkan Photoshop menyatakan bahwa ia akan selalu menggunakan alamat memori mulai dari 0hingga 1023(bayangkan memori sebagai array linier byte, jadi byte pertama berada di lokasi 0, 1024byte pertama berada di lokasi 1023) - yaitu menempati 1 GBmemori. Demikian pula, VLC menyatakan bahwa hal itu akan menempati rentang memori 1244untuk 1876, dll
Keuntungan:
- Setiap aplikasi telah diberi slot memori sebelumnya, jadi ketika diinstal dan dijalankan, itu hanya menyimpan datanya di area memori itu, dan semuanya berfungsi dengan baik.
Kekurangan:
Ini tidak berskala. Secara teoritis, sebuah aplikasi mungkin memerlukan memori dalam jumlah besar ketika melakukan sesuatu yang sangat berat. Jadi untuk memastikan bahwa memori tidak pernah habis, area memori yang dialokasikan padanya harus selalu lebih dari atau sama dengan jumlah memori tersebut. Bagaimana jika sebuah perangkat lunak, yang penggunaan memori teoritis maksimalnya 2 GB(karenanya memerlukan 2 GBalokasi memori dari RAM), dipasang di mesin dengan hanya 1 GBmemori? Haruskah perangkat lunak dibatalkan saat startup, dengan mengatakan bahwa RAM yang tersedia kurang dari 2 GB? Atau haruskah itu berlanjut, dan saat memori yang dibutuhkan melebihi 2 GB, batalkan saja dan bail out dengan pesan bahwa tidak cukup memori tersedia?
Memori tidak bisa rusak. Ada jutaan perangkat lunak di luar sana, bahkan jika masing-masing hanya dialokasikan 1 kBmemori, total memori yang dibutuhkan akan melebihi 16 GB, yang lebih dari yang ditawarkan kebanyakan perangkat. Bagaimana, kemudian, perangkat lunak yang berbeda dapat dialokasikan slot memori yang tidak mengganggu area masing-masing? Pertama, tidak ada pasar perangkat lunak terpusat yang dapat mengatur bahwa ketika perangkat lunak baru dirilis, ia harus menetapkan sendiri memori sebanyak ini dari area yang belum ditempati ini., dan kedua, bahkan jika ada, tidak mungkin melakukannya karena tidak ada. perangkat lunak praktis tidak terbatas (sehingga membutuhkan memori tak terbatas untuk menampung semuanya), dan total RAM yang tersedia pada perangkat apa pun tidak cukup untuk menampung bahkan sebagian kecil dari apa yang diperlukan, sehingga membuat batas memori yang tidak terelakkan dari satu perangkat lunak atas yang lain. Jadi apa yang terjadi ketika Photoshop ditugaskan lokasi memori 1untuk 1023dan VLC ditugaskan 1000ke 1676? Bagaimana jika Photoshop menyimpan beberapa data di lokasi 1008, kemudian VLC menimpanya dengan datanya sendiri, dan kemudian Photoshopmengaksesnya berpikir bahwa itu adalah data yang sama yang disimpan di sana sebelumnya? Seperti yang bisa Anda bayangkan, hal-hal buruk akan terjadi.
Jadi jelas, seperti yang Anda lihat, ide ini agak naif.
Solusi yang memungkinkan 2 : Mari coba skema lain - di mana OS akan melakukan sebagian besar manajemen memori. Perangkat lunak, kapan pun mereka membutuhkan memori, hanya akan meminta OS, dan OS akan mengakomodasi sesuai kebutuhan. Say OS memastikan bahwa setiap kali proses baru meminta memori, ia akan mengalokasikan memori dari alamat byte serendah mungkin (seperti yang dikatakan sebelumnya, RAM dapat dibayangkan sebagai array linier byte, jadi untuk 4 GBRAM, kisaran alamat untuk a byte dari 0hingga2^32-1) jika prosesnya dimulai, jika tidak, jika itu adalah proses yang sedang berjalan yang meminta memori, ia akan mengalokasikan dari lokasi memori terakhir tempat proses itu masih ada. Karena perangkat lunak akan memancarkan alamat tanpa mempertimbangkan alamat memori sebenarnya di mana data itu disimpan, OS harus memelihara pemetaan, per perangkat lunak, dari alamat yang dipancarkan oleh perangkat lunak ke alamat fisik sebenarnya (Catatan: itulah salah satu dari dua alasan kami menyebutnya konsep ini Virtual Memory. Perangkat lunak tidak peduli tentang alamat memori sebenarnya di mana datanya disimpan, mereka hanya memuntahkan alamat dengan cepat, dan OS menemukan tempat yang tepat untuk mencocokkannya dan menemukannya nanti jika diperlukan).
Katakanlah perangkat baru saja dihidupkan, OS baru saja diluncurkan, saat ini tidak ada proses lain yang berjalan (mengabaikan OS, yang juga merupakan proses!), Dan Anda memutuskan untuk meluncurkan VLC . Jadi VLC dialokasikan sebagian dari RAM dari alamat byte terendah. Baik. Sekarang saat video sedang berjalan, Anda perlu memulai browser Anda untuk melihat beberapa halaman web. Kemudian Anda perlu meluncurkan Notepad untuk mencoret-coret beberapa teks. Dan kemudian Eclipse untuk melakukan beberapa pengkodean .. Tak lama kemudian memori Anda 4 GBhabis, dan RAM terlihat seperti ini:
Masalah 1: Sekarang Anda tidak dapat memulai proses lain, karena semua RAM habis. Dengan demikian program harus ditulis dengan mengingat memori maksimum yang tersedia (praktis bahkan lebih sedikit yang tersedia, karena perangkat lunak lain akan berjalan paralel juga!). Dengan kata lain, Anda tidak dapat menjalankan aplikasi yang menghabiskan banyak memori di 1 GBPC bobrok Anda .
Oke, jadi sekarang Anda memutuskan bahwa Anda tidak perlu lagi membiarkan Eclipse dan Chrome terbuka, Anda menutupnya untuk mengosongkan sebagian memori. Ruang yang ditempati dalam RAM oleh proses tersebut diklaim kembali oleh OS, dan terlihat seperti ini sekarang:
Misalkan menutup keduanya akan membebaskan 700 MBruang - ( 400+ 300) MB. Sekarang Anda perlu meluncurkan Opera , yang akan menghabiskan 450 MBruang. Ya, Anda memang memiliki lebih dari 450 MBruang yang tersedia secara total, tapi ... itu tidak berdekatan, itu dibagi menjadi beberapa bagian, tidak ada yang cukup besar untuk muat 450 MB. Jadi Anda mendapatkan ide cemerlang, mari pindahkan semua proses di bawah ini ke atas sebanyak mungkin, yang akan menyisakan 700 MBruang kosong dalam satu bagian di bagian bawah. Ini disebutcompaction. Bagus, kecuali itu ... semua proses yang ada sedang berjalan. Memindahkannya berarti memindahkan alamat dari semua isinya (ingat, OS memelihara pemetaan memori yang dikeluarkan oleh perangkat lunak ke alamat memori sebenarnya. Bayangkan perangkat lunak telah mengeluarkan alamat 45dengan data 123, dan OS telah menyimpannya di lokasi 2012dan membuat entri di peta, memetakan 45ke 2012. Jika perangkat lunak sekarang dipindahkan ke memori, apa yang dulu ada di lokasi 2012tidak lagi berada di 2012, tetapi di lokasi baru, dan OS harus memperbarui peta sesuai dengan peta 45ke alamat baru, sehingga perangkat lunak bisa mendapatkan data yang diharapkan ( 123) ketika menanyakan lokasi 45memori.Sepanjang yang menyangkut perangkat lunak, yang diketahui hanyalah alamat itu45berisi data 123!)! Bayangkan sebuah proses yang mereferensikan variabel lokal i. Pada saat diakses lagi, alamatnya telah berubah, dan tidak dapat menemukannya lagi. Hal yang sama akan berlaku untuk semua fungsi, objek, variabel, pada dasarnya semuanya memiliki alamat, dan memindahkan proses berarti mengubah alamat semuanya. Yang membawa kita ke:
Masalah 2: Anda tidak dapat memindahkan proses. Nilai dari semua variabel, fungsi dan objek dalam proses tersebut memiliki nilai hardcode yang dikeluarkan oleh kompilator selama kompilasi, proses bergantung pada mereka berada di lokasi yang sama selama masa pakainya, dan mengubahnya mahal. Akibatnya, proses meninggalkan " holes" besar saat mereka keluar. Ini disebut
External Fragmentation.
Baik. Misalkan, entah bagaimana, dengan cara yang ajaib, Anda berhasil meningkatkan proses. Sekarang ada 700 MBruang kosong di bagian bawah:
Opera dengan mulus masuk di bagian bawah. Sekarang RAM Anda terlihat seperti ini:
Baik. Semuanya terlihat baik-baik saja. Namun, tidak banyak ruang yang tersisa, dan sekarang Anda perlu meluncurkan Chrome lagi, memori-hog yang terkenal! Dibutuhkan banyak memori untuk memulai, dan Anda hampir tidak memiliki yang tersisa ... Kecuali .. sekarang Anda memperhatikan bahwa beberapa proses, yang awalnya menempati ruang besar, sekarang tidak membutuhkan banyak ruang. Mungkin Anda telah menghentikan video Anda di VLC , karena itu masih menempati beberapa ruang, tetapi tidak sebanyak yang dibutuhkan saat menjalankan video resolusi tinggi. Begitu pula untuk Notepad dan Foto . RAM Anda sekarang terlihat seperti ini:
Holes, sekali lagi! Kembali ke awal! Kecuali, sebelumnya, lubang terjadi karena proses penghentian, sekarang karena proses yang membutuhkan lebih sedikit ruang dari sebelumnya! Dan Anda sekali lagi memiliki masalah yang sama, holesgabungan menghasilkan lebih banyak ruang daripada yang dibutuhkan, tetapi mereka tersebar di sekitar, tidak banyak digunakan dalam isolasi. Jadi, Anda harus memindahkan proses itu lagi, operasi yang mahal, dan yang sangat sering, karena proses akan sering berkurang ukurannya selama masa pakainya.
Masalah 3: Proses, selama masa pakainya, dapat berkurang ukurannya, meninggalkan ruang yang tidak terpakai, yang jika perlu digunakan, akan membutuhkan operasi yang mahal untuk memindahkan banyak proses. Ini disebut
Internal Fragmentation.
Baiklah, jadi sekarang, OS Anda melakukan hal yang diperlukan, memindahkan proses dan memulai Chrome dan setelah beberapa waktu, RAM Anda terlihat seperti ini:
Keren. Sekarang misalkan Anda kembali menonton Avatar di VLC . Persyaratan memorinya akan meningkat! Tapi ... tidak ada ruang tersisa untuk itu tumbuh, karena Notepad meringkuk di bawahnya. Jadi, sekali lagi, semua proses harus dipindahkan ke bawah sampai VLC menemukan ruang yang cukup!
Masalah 4: Jika proses perlu berkembang, ini akan menjadi operasi yang sangat mahal
Baik. Sekarang misalkan, Foto sedang digunakan untuk memuat beberapa foto dari hard disk eksternal. Mengakses hard-disk membawa Anda dari ranah cache dan RAM ke ranah disk, yang lebih lambat menurut urutan besarnya. Menyakitkan, tidak dapat dibatalkan, lebih lambat secara transendental. Ini adalah operasi I / O, yang berarti tidak terikat dengan CPU (justru sebaliknya), yang berarti tidak perlu menggunakan RAM sekarang. Namun, itu tetap menggunakan RAM dengan keras kepala. Jika Anda ingin meluncurkan Firefox untuk sementara waktu, Anda tidak bisa, karena tidak banyak memori yang tersedia, sedangkan jika Foto diambil dari memori selama aktivitas terikat I / O-nya, itu akan membebaskan banyak memori, diikuti oleh pemadatan (mahal), diikuti oleh pemasangan Firefox .
Masalah 5: Pekerjaan terikat I / O terus menempati RAM, yang menyebabkan penggunaan RAM yang rendah, yang bisa saja digunakan oleh pekerjaan terikat CPU untuk sementara.
Jadi, seperti yang bisa kita lihat, kita memiliki banyak masalah bahkan dengan pendekatan memori virtual.
Ada dua pendekatan untuk mengatasi masalah ini - pagingdan segmentation. Mari kita bahas paging. Dalam pendekatan ini, ruang alamat virtual dari suatu proses dipetakan ke memori fisik dalam potongan - disebut pages. pageUkuran tipikal adalah 4 kB. Pemetaan dikelola oleh sesuatu yang disebut a page table, diberi alamat virtual, yang harus kita lakukan adalah mencari tahu pagealamat mana , kemudian dari page table, menemukan lokasi yang sesuai untuk itu pagedi memori fisik aktual (dikenal sebagai frame), dan diberikan bahwa offset alamat virtual dalam pagesama untuk pagedan frame, cari tahu alamat sebenarnya dengan menambahkan offset itu ke alamat yang dikembalikan oleh page table. Sebagai contoh:
Di sebelah kiri adalah ruang alamat virtual dari suatu proses. Katakanlah ruang alamat virtual membutuhkan 40 unit memori. Jika ruang alamat fisik (di sebelah kanan) memiliki 40 unit memori juga, itu mungkin untuk memetakan semua lokasi dari kiri ke lokasi di sebelah kanan, dan kami akan sangat senang. Tapi sialnya, tidak hanya memori fisik memiliki lebih sedikit (24 di sini) unit memori yang tersedia, itu juga harus dibagi di antara banyak proses! Baiklah, mari kita lihat bagaimana kita melakukannya.
Saat proses dimulai, ucapkan permintaan akses memori untuk lokasi 35dibuat. Di sini ukuran halaman 8(masing page- masing berisi 8lokasi, seluruh ruang alamat virtual 40lokasi berisi 5halaman). Jadi lokasi ini milik halaman no. 4( 35/8). Dalam ini page, lokasi ini memiliki offset 3( 35%8). Jadi lokasi ini dapat ditentukan oleh tuple (pageIndex, offset)= (4,3). Ini baru permulaan, jadi belum ada bagian dari proses yang disimpan dalam memori fisik sebenarnya. Jadi page table, yang memelihara pemetaan halaman di sebelah kiri ke halaman sebenarnya di sebelah kanan (di mana mereka dipanggilframes) saat ini kosong. Jadi OS melepaskan CPU, memungkinkan driver perangkat mengakses disk dan mengambil halaman no. 4untuk proses ini (pada dasarnya potongan memori dari program pada disk yang alamatnya berkisar dari 32hingga 39). Ketika tiba, OS mengalokasikan halaman di suatu tempat di RAM, katakanlah bingkai pertama itu sendiri, dan page tableuntuk proses ini perhatikan bahwa 4peta halaman ke bingkai 0dalam RAM. Sekarang data tersebut akhirnya ada di memori fisik. OS kembali menanyakan tabel halaman untuk tupel (4,3), dan kali ini, tabel halaman mengatakan bahwa halaman 4sudah dipetakan ke bingkai 0dalam RAM. Jadi OS hanya pergi ke 0frame ke dalam RAM, mengakses data di offset 3dalam frame itu (Luangkan waktu sejenak untuk memahami ini.page, yang diambil dari disk, dipindahkan ke frame. Jadi, apa pun offset lokasi memori individu dalam sebuah halaman, itu akan sama di bingkai juga, karena di dalam page/ frame, unit memori masih berada di tempat yang relatif sama!), Dan mengembalikan data! Karena data tidak ditemukan di memori pada permintaan pertama itu sendiri, melainkan harus diambil dari disk yang akan dimuat ke memori, itu merupakan kehilangan .
Baik. Sekarang misalkan, akses memori untuk lokasi 28dibuat. Itu intinya (3,4). Page tablesekarang hanya memiliki satu entri, memetakan halaman 4ke bingkai 0. Jadi ini adalah lagi rindu , proses relinquishes CPU, device driver menjemput halaman dari disk, proses mendapatkan kembali kontrol dari CPU lagi, dan yang page tablediperbarui. Katakanlah sekarang halaman 3tersebut dipetakan ke frame 1dalam RAM. Jadi (3,4)menjadi (1,4), dan data di lokasi itu di RAM dikembalikan. Baik. Dengan cara ini, misalkan akses memori berikutnya adalah untuk lokasi 8, yang diterjemahkan menjadi (1,0). Halaman 1belum ada dalam memori, prosedur yang sama diulangi, dan pagedialokasikan pada frame2dalam RAM. Sekarang pemetaan proses RAM terlihat seperti gambar di atas. Pada titik ini, RAM, yang hanya memiliki 24 unit memori yang tersedia, sudah terisi. Misalkan permintaan akses memori berikutnya untuk proses ini adalah dari alamat 30. Itu memetakan ke (3,6), dan page tablemengatakan bahwa halaman itu 3ada dalam RAM, dan itu memetakan ke bingkai 1. Yay! Jadi data diambil dari lokasi RAM (1,6), dan dikembalikan. Ini merupakan hit , karena data yang dibutuhkan dapat diperoleh langsung dari RAM, sehingga menjadi sangat cepat. Demikian pula, beberapa permintaan akses berikutnya, mengatakan untuk lokasi 11, 32, 26, 27semua hit , yaitu data yang diminta oleh proses ini ditemukan langsung di RAM tanpa perlu mencari di tempat lain.
Sekarang misalkan permintaan akses memori untuk lokasi 3datang. Ini diterjemahkan menjadi (0,3), dan page tableuntuk proses ini, yang saat ini memiliki 3 entri, untuk halaman 1, 3dan 4mengatakan bahwa halaman ini tidak ada dalam memori. Seperti kasus sebelumnya, ini diambil dari disk, namun, tidak seperti kasus sebelumnya, RAM terisi! Lalu apa yang harus dilakukan sekarang? Di sinilah letak keindahan virtual memory, sebuah frame dari RAM digusur! (Berbagai faktor mengatur frame mana yang akan digusur. Mungkin LRUdidasarkan, di mana frame yang paling terakhir diakses untuk suatu proses akan digusur. Mungkin menjadi first-come-first-evicteddasar, di mana frame yang dialokasikan paling lama lalu, digusur, dll. .) Jadi, beberapa bingkai digusur. Ucapkan frame 1 (pilih saja secara acak). Namun, itu framedipetakan ke beberapapage! (Saat ini, itu dipetakan oleh tabel halaman ke halaman 3dari satu dan hanya satu proses kami). Jadi proses itu harus menyampaikan berita tragis ini frame, yang malang milik Anda, harus dikeluarkan dari RAM untuk memberi ruang bagi yang lain pages. Proses harus memastikan bahwa ia memperbaruinya page tabledengan informasi ini, yaitu, menghapus entri untuk duo bingkai halaman itu, sehingga saat permintaan dibuat untuk itu page, itu benar memberi tahu proses bahwa ini pagetidak lagi dalam memori , dan harus diambil dari disk. Baik. Jadi bingkai dikeluarkan, 1halaman 0dibawa masuk dan ditempatkan di sana di RAM, dan entri untuk halaman 3dihapus, dan diganti dengan 0pemetaan halaman ke bingkai yang sama1. Jadi sekarang pemetaan kami terlihat seperti ini (perhatikan perubahan warna di detik framedi sisi kanan):
Lihat apa yang baru saja terjadi? Prosesnya harus berkembang, itu membutuhkan lebih banyak ruang daripada RAM yang tersedia, tetapi tidak seperti skenario kami sebelumnya di mana setiap proses dalam RAM harus dipindahkan untuk mengakomodasi proses yang berkembang, ini terjadi hanya dengan satu pagepenggantian! Ini dimungkinkan oleh fakta bahwa memori untuk suatu proses tidak lagi perlu bersebelahan, ia dapat berada di tempat yang berbeda dalam potongan, OS menyimpan informasi di mana mereka berada, dan bila diperlukan, mereka ditanyai dengan tepat. Catatan: Anda mungkin berpikir, huh, bagaimana jika sebagian besar adalah a miss, dan data harus terus-menerus dimuat dari disk ke memori? Ya, secara teoritis, itu mungkin, tetapi sebagian besar kompiler dirancang sedemikian rupa sebagai berikutlocality of reference, yaitu jika data dari beberapa lokasi memori digunakan, data berikutnya yang dibutuhkan akan ditempatkan di suatu tempat yang sangat dekat, mungkin dari tempat yang sama page, pageyang baru saja dimuat ke dalam memori. Akibatnya, kehilangan berikutnya akan terjadi setelah beberapa waktu, sebagian besar persyaratan memori yang akan datang akan dipenuhi oleh halaman yang baru saja dibawa masuk, atau halaman yang sudah ada dalam memori yang baru saja digunakan. Prinsip yang sama persis memungkinkan kita untuk mengusir yang paling terakhir digunakan pagejuga, dengan logika bahwa apa yang sudah lama tidak digunakan, kemungkinan besar juga tidak akan digunakan untuk sementara waktu. Namun, tidak selalu demikian, dan dalam kasus luar biasa, ya, kinerja dapat menurun. Lebih lanjut tentang itu nanti.
Solusi untuk Masalah 4: Proses sekarang dapat berkembang dengan mudah, jika masalah ruang dihadapkan, yang diperlukan hanyalah melakukan pagepenggantian sederhana , tanpa memindahkan proses lain.
Solusi untuk Masalah 1: Suatu proses dapat mengakses memori tak terbatas. Ketika lebih banyak memori dari yang tersedia diperlukan, disk digunakan sebagai cadangan, data baru yang diperlukan dimuat ke dalam memori dari disk, dan data yang paling terakhir digunakan frame(atau page) dipindahkan ke disk. Ini bisa berlangsung tanpa batas, dan karena ruang disk murah dan hampir tidak terbatas, ini memberikan ilusi memori tak terbatas. Alasan lain untuk namanya Virtual Memory, itu memberi Anda ilusi memori yang sebenarnya tidak tersedia!
Keren. Sebelumnya kami menghadapi masalah di mana meskipun suatu proses berkurang ukurannya, ruang kosong sulit untuk diklaim kembali oleh proses lain (karena akan membutuhkan pemadatan yang mahal). Sekarang mudah, ketika ukuran proses menjadi lebih kecil, banyak di pagesantaranya tidak lagi digunakan, jadi ketika proses lain membutuhkan lebih banyak memori, LRUpenggusuran berbasis sederhana secara otomatis mengusir mereka yang kurang digunakan pagesdari RAM, dan menggantinya dengan halaman baru dari proses lainnya (dan tentu saja memperbarui page tablessemua proses tersebut serta proses asli yang sekarang membutuhkan lebih sedikit ruang), semua ini tanpa operasi pemadatan yang mahal!
Solusi untuk Masalah 3: Setiap kali proses berkurang ukurannya, framesdalam RAM-nya akan lebih sedikit digunakan, sehingga LRUpenggusuran berbasis sederhana dapat mengeluarkan halaman-halaman itu dan menggantinya dengan yang pagesdiperlukan oleh proses baru, sehingga menghindari Internal Fragmentationtanpa perlu compaction.
Adapun masalah 2, luangkan waktu sejenak untuk memahami ini, skenarionya sendiri sudah sepenuhnya dihapus! Tidak perlu memindahkan suatu proses untuk mengakomodasi proses baru, karena sekarang seluruh proses tidak pernah perlu muat sekaligus, hanya halaman tertentu saja yang perlu disesuaikan ad hoc, yang terjadi dengan mengeluarkan framesdari RAM. Semuanya terjadi dalam satuan pages, jadi tidak ada konsep tentang holesekarang, dan karenanya tidak ada pertanyaan tentang apa pun yang bergerak! Mungkin 10 pagesharus dipindahkan karena persyaratan baru ini, yang masih ribuan di pagesantaranya tidak tersentuh. Padahal, sebelumnya, semua proses (setiap bagiannya) harus dipindahkan!
Solusi untuk Masalah 2: Untuk mengakomodasi proses baru, data dari bagian proses lain yang baru-baru ini digunakan harus dikeluarkan sesuai kebutuhan, dan ini terjadi dalam unit ukuran tetap yang disebut pages. Dengan demikian tidak ada kemungkinan holeatau External Fragmentationdengan sistem ini.
Sekarang ketika proses perlu melakukan beberapa operasi I / O, proses tersebut dapat melepaskan CPU dengan mudah! OS hanya mengeluarkan semua pagesdari RAM (mungkin menyimpannya di beberapa cache) sementara proses baru menempati RAM sementara itu. Ketika operasi I / O selesai, OS hanya mengembalikannya pageske RAM (tentu saja dengan mengganti pagesdari beberapa proses lain, mungkin dari proses yang menggantikan proses asli, atau mungkin dari beberapa yang perlu melakukan I / O sekarang, dan karenanya dapat melepaskan ingatan!)
Solusi untuk Masalah 5: Ketika suatu proses melakukan operasi I / O, itu dapat dengan mudah melepaskan penggunaan RAM, yang dapat dimanfaatkan oleh proses lain. Ini mengarah pada pemanfaatan RAM yang tepat.
Dan tentu saja, sekarang tidak ada proses yang mengakses RAM secara langsung. Setiap proses mengakses lokasi memori virtual, yang dipetakan ke alamat RAM fisik dan dikelola oleh page-tableproses itu. Pemetaan ini didukung OS, OS memungkinkan proses mengetahui frame mana yang kosong sehingga halaman baru untuk suatu proses dapat dipasang di sana. Karena alokasi memori ini diawasi oleh OS itu sendiri, ia dapat dengan mudah memastikan bahwa tidak ada proses yang mengganggu konten dari proses lain dengan hanya mengalokasikan frame kosong dari RAM, atau saat melanggar konten dari proses lain di RAM, berkomunikasi dengan proses tersebut. untuk memperbaruinya page-table.
Solusi untuk Masalah Asli: Tidak ada kemungkinan proses mengakses konten dari proses lain, karena seluruh alokasi dikelola oleh OS itu sendiri, dan setiap proses berjalan di ruang alamat virtual sandboxnya sendiri.
Jadi paging(di antara teknik lainnya), dalam hubungannya dengan memori virtual, adalah kekuatan perangkat lunak saat ini yang berjalan di OS-es! Ini membebaskan pengembang perangkat lunak dari kekhawatiran tentang berapa banyak memori yang tersedia pada perangkat pengguna, di mana untuk menyimpan data, bagaimana mencegah proses lain merusak data perangkat lunak mereka, dll. Namun, tentu saja ini tidak sepenuhnya terbukti. Ada kekurangannya:
Pagingadalah, pada akhirnya, memberikan ilusi memori tak terbatas kepada pengguna dengan menggunakan disk sebagai cadangan sekunder. Mengambil data dari penyimpanan sekunder untuk dimasukkan ke dalam memori (disebut page swap, dan peristiwa tidak menemukan halaman yang diinginkan dalam RAM disebut page fault) mahal karena ini adalah operasi IO. Ini memperlambat proses. Beberapa pertukaran halaman seperti itu terjadi secara berurutan, dan prosesnya menjadi sangat lambat. Pernah melihat perangkat lunak Anda berjalan dengan baik dan keren, dan tiba-tiba menjadi sangat lambat sehingga hampir hang, atau membuat Anda tidak memiliki opsi untuk memulai ulang? Mungkin terlalu banyak pertukaran halaman yang terjadi, membuatnya lambat (disebut thrashing).
Jadi kembali ke OP,
Mengapa kita membutuhkan memori virtual untuk menjalankan suatu proses? - Seperti yang dijelaskan secara panjang lebar oleh jawaban, untuk memberikan ilusi perangkat lunak perangkat / OS yang memiliki memori tak terbatas, sehingga perangkat lunak apa pun, besar atau kecil, dapat dijalankan, tanpa mengkhawatirkan alokasi memori, atau proses lain yang merusak datanya, bahkan ketika berjalan secara paralel. Suatu konsep yang diimplementasikan dalam praktek melalui berbagai teknik, salah satunya seperti yang dijelaskan di sini adalah Paging . Mungkin juga Segmentasi .
Di manakah posisi memori virtual ini ketika proses (program) dari hard drive eksternal dibawa ke memori utama (memori fisik) untuk dieksekusi? - Memori virtual tidak berdiri sendiri di mana pun, itu adalah abstraksi, selalu ada, ketika perangkat lunak / proses / program di-boot, tabel halaman baru dibuat untuknya, dan berisi pemetaan dari alamat yang dikeluarkan oleh itu proses ke alamat fisik sebenarnya di RAM. Karena alamat yang dikeluarkan oleh proses bukanlah alamat sebenarnya, di satu sisi, alamat tersebut sebenarnya adalah apa yang dapat Anda katakan , the virtual memory.
Siapa yang mengurus memori virtual dan berapa ukuran memori virtual? - Ini diurus oleh, bersama-sama, OS dan perangkat lunak. Bayangkan sebuah fungsi dalam kode Anda (yang akhirnya dikompilasi dan dibuat menjadi dapat dieksekusi yang melahirkan proses) yang berisi variabel lokal - an int i. Saat kode dijalankan, idapatkan alamat memori di dalam tumpukan fungsi. Fungsi itu sendiri disimpan sebagai objek di tempat lain. Alamat-alamat ini dihasilkan oleh kompilator (kompilator yang mengkompilasi kode Anda ke dalam eksekusi) - alamat virtual. Ketika dijalankan, iharus berada di suatu tempat di alamat fisik sebenarnya selama fungsi itu setidaknya (kecuali itu adalah variabel statis!), Jadi OS memetakan alamat virtual yang dihasilkan kompilatorike alamat fisik aktual, sehingga kapan pun, dalam fungsi itu, beberapa kode memerlukan nilai i, proses itu dapat menanyakan OS untuk alamat virtual itu, dan OS pada gilirannya dapat menanyakan alamat fisik untuk nilai yang disimpan, dan mengembalikannya.
Misalkan jika ukuran RAM adalah 4GB (yaitu 2 ^ 32-1 ruang alamat) berapakah ukuran memori virtual? - Ukuran RAM tidak terkait dengan ukuran memori virtual, itu tergantung pada OS. Misalnya, pada Windows 32 bit 16 TB, pada Windows 64 bit, ini adalah 256 TB. Tentu saja, ini juga dibatasi oleh ukuran disk, karena di situlah memori dicadangkan.