memory-management - У чому різниця між віртуальною пам'яттю і фізичної пам'яттю? - Qaru

Програмне забезпечення працює в ОС з дуже простої передумовою - їм потрібно пам'ять. ОС пристрою надає його у вигляді оперативної пам'яті. Необхідний обсяг пам'яті може варіюватися - деяким програмам потрібна величезна пам'ять, іншим - мізерна пам'ять. Більшість (якщо не всі) користувачі одночасно запускають кілька додатків в ОС, і, з огляду на, що пам'ять дорога (а розмір пристрою кінцевий), обсяг доступної пам'яті завжди обмежений. Таким чином, з огляду на, що для всіх програм потрібен певний обсяг ОЗУ, і всі вони можуть працювати одночасно, ОС повинна подбати про дві речі:

1. Це програмне забезпечення завжди запускається до тих пір, поки користувач не перерве його, тобто воно не повинно автоматично перериватися, тому що ОС не вистачає пам'яті.
2. Вищевказані дії, зберігаючи при цьому респектабельну продуктивність для працюючих програм.

Тепер головне питання зводиться до того, як пам'ять управляється. Що саме визначає, де в пам'яті будуть знаходитися дані, що належать даному програмному забезпеченню?

Можливе рішення 1. Дозвольте окремими програмами явно вказувати адресу пам'яті, який вони використовуватимуть в пристрої. Припустимо, Photoshop заявляє, що він завжди буде використовувати адреси пам'яті в діапазоні від 0 до 1023 (уявіть, що пам'ять є лінійний масив байтів, тому перший байт знаходиться в комірці 0, 1024 й байт знаходиться в комірці 1023), тобто займає 1 GB пам'яті. Аналогічно, VLC заявляє, що він буде займати діапазон пам'яті від +1244 до 1876 і т.д.

переваги:

1. Кожному з додатком заздалегідь призначається слот пам'яті, тому, коли воно встановлено і виконано, воно просто зберігає свої дані в цій області пам'яті, і все працює нормально.

недоліки:

1. Це не масштабується. Теоретично, з додатком може знадобитися велика кількість пам'яті, коли воно виконує щось дійсно важке. Таким чином, щоб гарантувати, що він ніколи не вичерпає пам'ять, виділена йому область пам'яті завжди повинна бути більше або дорівнює цього обсягу пам'яті. Що якщо програмне забезпечення, чиє максимальне теоретичне використання пам'яті становить 2 GB (отже, потрібно 2 GB виділення пам'яті з ОЗУ), встановлено на машині, що має тільки 1 GB пам'яті? Чи повинно програмне забезпечення просто перериватися при запуску, кажучи, що доступна оперативна пам'ять становить менше 2 GB? Або це має тривати, і в той момент, коли необхідна пам'ять перевищує 2 GB, просто перервіться і виведіть повідомлення про те, що недостатньо пам'яті?

2. Неможливо запобігти спотворення пам'яті. Існують мільйони програм, навіть якщо кожному з них було виділено всього 1 kB пам'яті, загальний обсяг необхідної пам'яті перевищив би 16 GB, що більше, ніж пропонує більшість пристроїв. Як же тоді різними програмами можна виділити слоти пам'яті, які не зачіпають один одного? По-перше, немає централізованого ринку програмного забезпечення, який міг би регулювати те, що при випуску нового програмного забезпечення він повинен виділяти собі стільки пам'яті з цієї ще не зайнятою області, а по-друге, навіть якби він був, це неможливо зробити, тому що немає. програмного забезпечення практично нескінченна (таким чином, потрібно нескінченна пам'ять для розміщення всіх з них), і загального обсягу оперативної пам'яті, доступної на будь-якому пристрої, недостатньо для розміщення навіть частини того, що потрібно, що робить неминучим вторгнення в межі пам'яті одного програмного забезпечення на це іншого. Так що ж відбувається, коли Photoshop призначається область пам'яті від 1 до 1023 а VLC призначається від 1000 до 1676? Що якщо Photoshop зберігає деякі дані в місці розташування 1008, тоді VLC перезаписує їх своїми власними даними, і пізніше Photoshop звертається до них, думаючи, що це ті ж самі дані, які зберігалися там раніше? Як ви можете собі уявити, погані речі будуть відбуватися.

Так ясно, як бачите, ця ідея досить наївна.

Можливе рішення 2: Давайте спробуємо іншу схему - де ОС буде робити велику частину управління пам'яттю. Програмне забезпечення, коли йому потрібно будь-яка пам'ять, просто запитує ОС, і ОС буде пристосовуватися відповідно. Скажімо, ОС гарантує, що всякий раз, коли новий процес запитує пам'ять, вона виділяє пам'ять з мінімально можливого байтового адреси (як було сказано раніше, ОЗУ можна уявити як лінійний масив байтів, тому для ОЗУ 4 GB діапазон адрес для байта від 0 до 2 ^ 32-1) якщо процес запускається, інакше, якщо це запущений процес, запитувач пам'ять, він буде виділятися з останньої області пам'яті, де цей процес все ще знаходиться. Оскільки програмне забезпечення буде відправляти адреси без урахування того, яким буде фактична адреса пам'яті, де зберігаються ці дані, ОС повинна буде підтримувати відображення для кожного програмного забезпечення адреси, що випускається програмним забезпеченням, на фактичний фізичну адресу (Примітка: це одна з двох причин, по яким ми називаємо цю концепцію Virtual Memory програмами не важливий реальну адресу пам'яті, де зберігаються їхні дані, вони просто викладають адреси на льоту, і ОС знаходить відповідне місце для цього і знайдіть його пізніше, якщо знадобиться).

Скажімо, пристрій тільки що включилося, ОС тільки що запустилася, зараз немає іншого запущеного процесу (ігноруючи ОС, який також є процесом!), І ви вирішуєте запустити VLC. Таким чином, VLC виділяється частина оперативної пам'яті з молодших байтових адрес. Добре. Тепер, поки йде відео, вам потрібно запустити браузер для перегляду будь-якої веб-сторінки. Потім вам потрібно запустити Блокнот, щоб накидати текст. І потім Eclipse, щоб зробити деякий кодування. Досить скоро ваша пам'ять 4 GB повністю витрачена, і ОЗУ виглядає наступним чином:

Проблема 1: Тепер ви не можете запустити будь-який інший процес, так як вся оперативна пам'ять витрачена. Таким чином, програми повинні бути написані з урахуванням максимальної доступної пам'яті (практично навіть менше буде доступно, так як інші програми будуть працювати паралельно!). Іншими словами, ви не можете запустити додаток з високим споживанням пам'яті на своєму старому ПК 1 GB.

Отже, тепер ви вирішуєте, що вам більше не потрібно тримати Eclipse і Chrome відкритими, ви закриваєте їх, щоб звільнити частину пам'яті. Простір, займане цими процесами в оперативній пам'яті, використовується ОС, і тепер це виглядає так:

Припустимо, що ці два звільняють 700 MB простору - (400 + 300) МБ. Тепер вам потрібно запустити Opera, яка займе 450 MB простору. Що ж, у вас є в цілому більш 450 MB вільного місця, але ... воно не є суміжним, воно розділене на окремі шматки, жоден з яких не досить великий, щоб вмістити 450 MB. Таким чином, ви натрапили на блискучу ідею, дозвольте перемістити всі процеси нижче якомога вище, щоб залишити 700 MB порожнього простору в одному блоці внизу. Це називається compaction. Відмінно, хіба що ... всі процеси, які там є, запущені. Переміщення їх буде означати переміщення адреси всього їх вмісту (пам'ятаєте, ОС підтримує відображення пам'яті, що виділяється програмним забезпеченням, на фактичну адресу пам'яті. Уявіть, що програмне забезпечення видало адресу 45 з даними 123, а ОС зберегла його в місці розташування 2012 і створив запис на мапі , зіставляючи 45 з 2012 Якщо програмне забезпечення тепер переміщено в пам'яті, то, що було в місці розташування 2012 більше не буде в 2012, але в новому місці розташування, і ОС повинна буде оновити карта відповідає карті 45 з новою адресою, так що програмне забезпечення може отримати очікувані дані (123), коли вона запитує осередок пам'яті 45 Що стосується програмного забезпечення, все, що йому відомо, це те, що адреса 45 містить дані 123!)! Уявіть собі процес, який посилається на локальну змінну i. На той час, коли до нього знову отримають доступ, його адреса зміниться, і він більше не зможе його знайти. Те ж саме відноситься до всіх функцій, об'єктів, змінним, в основному всі мають адресу, і переміщення процесу буде означати зміну адреси всіх з них. Що приводить нас до:

Проблема 2: Ви не можете перемістити процес. Значення всіх змінних, функцій і об'єктів в цьому процесі мають жорстко задані значення, які виводяться компілятором під час компіляції, процес залежить від того, чи знаходяться вони в одному і тому ж місці протягом свого часу життя, і їх зміна обходиться дорого. В результаті процеси залишають після себе великі "holes". Це називається External Fragmentation.

Добре. Припустимо, якимось дивним чином вам вдалося просунути процеси вгору. Тепер внизу 700 MB вільного місця:

Опера плавно вписується внизу. Тепер ваша RAM виглядає так:

Добре. Все виглядає добре. Проте, залишилося не так багато місця, і тепер вам потрібно знову запустити Chrome, відомого бога пам'яті! Для запуску потрібно багато пам'яті, і у вас майже нічого не залишилося ... За винятком того, що ... тепер ви помітили, що деяким процесам, які спочатку займали великий простір, тепер не потрібно багато місця. Можливо, ви зупинили свій відео в VLC, отже, воно все ще займає деякий місце, але не так багато, як потрібно для роботи з відео високої роздільної здатності. Аналогічно для блокнота і фотографій. Ваша RAM тепер виглядає так:

Holes, ще раз! Повертається на круги своя! За винятком того, що раніше дірки виникали через припинення процесів, а тепер через процеси, що вимагають менше місця, ніж раніше! І у вас знову та ж проблема: об'єднані holes дають більше місця, ніж потрібно, але вони розкидані навколо, і не так багато використовуються в ізоляції. Таким чином, вам доведеться знову переміщати ці процеси, що є дорогою і дуже частою операцією, оскільки процеси часто зменшуються в розмірах протягом терміну служби.

Проблема 3: Процеси протягом терміну їх служби можуть зменшуватися в розмірах, залишаючи простір, який, яке, в разі необхідності, потребують дорогої операції переміщення багатьох процесів. Це називається Internal Fragmentation.

Добре, тепер ваша ОС виконує необхідні дії, переміщує процеси і запускає Chrome, а через деякий час ваша RAM виглядає наступним чином:

Здорово. Тепер припустимо, що ви знову відновили переглядали Аватар в VLC. Його вимога до пам'яті буде рости! Але ... йому не залишилося місця для зростання, оскільки Блокнот притискається до його нижньої частини. Отже, знову ж таки, все процеси повинні рухатися нижче, поки VLC не знайде достатньо місця!

Проблема 4: Якщо процеси повинні рости, це буде дуже дорога операція

Добре. Тепер припустимо, що Фото використовується для завантаження деяких фотографій з зовнішнього жорсткого диска. Доступ до жорсткого диска переносить вас з області кешей і ОЗУ в область диска, яка на кілька порядків повільніше. Аж надто, безповоротно, захмарно повільніше. Це операція введення-виведення, яка означає, що вона не пов'язана з процесором (це скоріше повна протилежність), що означає, що їй не потрібно зараз займати ОЗУ. Тим не менш, вона як і раніше займає RAM наполегливо. Якщо ви хочете запустити Firefox у той же час, ви не можете цього зробити, тому що не так багато пам'яті доступно, в той час як якщо б фотографії були видалені з пам'яті на час дії, пов'язаного з введенням / висновком, це звільнило б багато пам'яті , з подальшим (дорогим) ущільненням, за яким слід вставка Firefox.

Проблема 5: Завдання, пов'язані з введенням / висновком, продовжують займати ОЗУ, що призводить до недостатнього використання ОЗУ, яке в той же час могло використовуватися завданнями, пов'язаними з ЦП.

Отже, як ми бачимо, у нас так багато проблем, навіть з використанням віртуальної пам'яті.

Існує два підходи до вирішення цих проблем - paging і segmentation. Давайте обговоримо paging. При такому підході ВАП процесу відображається на фізичну пам'ять порціями - так званими pages. Типовий розмір page становить 4 kB. Зіставлення підтримується за допомогою чогось, званого page table, з урахуванням віртуального адреси. Тепер все, що нам потрібно зробити, це з'ясувати, до якої page належить адреса, а потім з page table знайти відповідного місця для цієї page в реальній фізичній пам'яті (відомий як frame), і враховуючи, що зміщення ВА на page однаково для page і frame, визначте фактичну адресу, додавши це зміщення до адресою, поверненого page table. наприклад:

Зліва - віртуальний адресний простір процесу. Скажімо, віртуальний адресний простір вимагає 40 одиниць пам'яті. Якби в фізичному адресному просторі (праворуч) також було 40 одиниць пам'яті, було б можливо відобразити всі місця розташування зліва на місце розташування праворуч, і ми були б дуже раді. Але, як не пощастило, фізична пам'ять не тільки має менше (24 тут) доступних блоків пам'яті, але і повинна бути розподілена між кількома процесами! Добре, давайте подивимося, як ми впораємося з цим.

Коли процес починається, скажімо, зроблений запит доступу до пам'яті для розташування 35. Тут розмір сторінки становить 8 (кожна page містить 8 місць розташування, таким чином, всі віртуальний адресний простір з 40 місцезнаходжень містить 5 сторінок). Так що це місце належить сторінці №. 4 (35/8). На цій page це місце розташування має зміщення 3 (35% 8). Таким чином, це місце розташування може бути зазначено за допомогою кортежу (pageIndex, offset) = (4,3). Це тільки початок, тому ніяка частина процесу ще не збережена в реальній фізичній пам'яті. Таким чином, page table, яка підтримує відображення сторінок зліва на фактичні сторінки праворуч (де вони називаються frames), в даний час порожня. Таким чином, ОС звільняє процесор, дозволяє драйверу пристрою отримати доступ до диска і отримати сторінку №. 4 для цього процесу (в основному це фрагмент пам'яті програми на диску з адресами від 32 до 39). Коли він надходить, ОС виділяє сторінку десь в ОЗУ, скажімо, сам перший кадр, і page table для цього процесу бере до відома, що сторінка 4 відображається в 0 кадр в ОЗУ. Тепер дані нарешті є у фізичній пам'яті. ОС знову запитує таблицю сторінок для кортежу (4,3), і на цей раз таблиця сторінок каже, що сторінка 4 вже порівняна з кадром 0 в ОЗУ. Таким чином, ОС просто переходить до 0 го кадру в ОЗУ, отримує доступ до даних зі зміщенням 3 в цьому кадрі (Знайдіть хвилинку, щоб зрозуміти це. Вся page, яка була витягнута з диска, переміщається в frame. Так що, незалежно від зміщення індивідуальне розташування пам'яті на сторінці було, воно буде таким же і у фреймі, оскільки всередині page / frame блок пам'яті все ще знаходиться в одному і тому ж місці щодо!) і повертає дані! Оскільки дані не були знайдені в пам'яті при першому запиті, а скоріше повинні були бути вилучені з диска для завантаження в пам'ять, це є пропуском.

Добре. Тепер припустимо, що доступ до пам'яті для розташування 28 зроблений. Це зводиться до (3,4). Page table зараз має тільки один запис, що відображає сторінку 4 в кадр 0. Так що це знову промах, процес звільняє процесор, драйвер пристрою витягує сторінку з диска, процес знову відновлює управління процесором, і його page table оновлюється. Скажімо, тепер сторінка 3 порівняна з кадром 1 в ОЗУ. Таким чином, (3,4) стає (1,4), і дані в цьому місці в ОЗУ повертаються. Добре. Таким чином, припустимо, що наступний доступ до пам'яті для розташування 8, що перекладається в (1,0). Сторінка 1 ще не знаходиться в пам'яті, та ж сама процедура повторюється, і page виділяється в кадрі 2 в ОЗУ. Тепер відображення RAM-процесу виглядає як на малюнку вище. На даний момент ОЗУ, в якому було доступно тільки 24 одиниці пам'яті, заповнене. Припустимо, що наступний запит доступу до пам'яті для цього процесу з адреси 30. Він відображається на (3,6), а page table каже, що сторінка 3 знаходиться в ОЗУ, і відображається на кадр 1. Ура! Таким чином, дані вибираються з ОЗУ (1,6) і повертаються. Це є хітом, оскільки необхідні дані можуть бути отримані безпосередньо з ОЗУ, що робить їх дуже швидкими. Аналогічно, наступні кілька запитів доступу, скажімо, для розташування 11, 32, 26, 27 все є влученнями, тобто дані, запитані процесом, перебувають безпосередньо в ОЗУ без необхідності шукати в іншому місці.

Тепер пріпустімо, что запит на доступ до пам'яті для Розташування 3 приходити. Це переводити в (0,3), и page table для цього процесса, яка в Сейчас годину має 3 записи, для сторінок 1, 3 і 4 говорити, что ця сторінка НЕ знаходиться в пам'яті. Як и в попередніх випадка, ВІН вітягується з диска, проти, На Відміну Від попередніх віпадків, ОЗУ заповнений! Так що ж тепер робити? Тут кріється краса віртуальної пам'яті, кадр з ОЗУ Виселення! (Різні чинники визначають, який кадр повинен бути знищений. Він може бути заснований на LRU, де повинен бути LRU кадр, до якого був здійснений найменший доступ для процесу. Це може бути принцип "first-come-first-evicted, де кадр, який виділив давним-давно виселяють і т.д.) Так що деякі рамки виселяють. Скажіть кадр 1 (просто випадково вибравши його). Тим не менш, цей frame відображається на якийсь page! (в даний час це відображається в таблиці сторінок нашого єдиного і єдиного процесу на сторінці 3). Таким чином, цього процесу потрібно з общіть цю трагічну новину, що один frame, який, на жаль, належить вам, повинен бути вилучений з ОЗУ, щоб звільнити місце для інших pages. Процес повинен переконатися, що він оновлює свою page table з цією інформацією, тобто видаляє запис для цього дуету фрейма сторінки, щоб наступного разу, коли запит був зроблений для цієї page, він правильно повідомив процесу, що ця page більше не в пам'яті, і повинен бути витягнутий з диска. Добре. Таким чином, кадр 1 є виселений, сторінка 0 вноситься в і поміщена там в RAM, а також запис для сторінки 3 видаляється і замінюється на сторінці 0 відображення однієї і тієї ж рамку 1. Отже, тепер наше відображення виглядає наступним чином (зверніть увагу на зміна кольору в другому frame з правого боку):

Бачив, що тільки що сталося? Процес повинен був рости, йому було потрібно більше місця, ніж доступною оперативної пам'яті, але на відміну від нашого більш раннього сценарію, коли кожен процес в оперативній пам'яті повинен був переміщатися, щоб пристосуватися до зростаючого процесу, тут це відбувалося всього лише однією заміною page! Це стало можливим завдяки тому факту, що пам'ять для процесу більше не повинна бути суміжною, вона може перебувати в різних місцях по частинах, ОС зберігає інформацію про те, де вони знаходяться, і при необхідності їх запитують відповідним чином. Примітка: ви можете подумати, а що якщо в більшості випадків це miss, і дані повинні постійно завантажуватися з диска в пам'ять? Так, теоретично це можливо, але більшість компіляторів спроектовано таким чином, що слід locality of reference, тобто якщо використовуються дані з деякого місця в пам'яті, такі необхідні дані будуть розташовані десь дуже близько, можливо, з тієї ж page, page яка була тільки що завантажена в пам'ять. В результаті така помилка станеться через деякий час, більшість майбутніх вимог до пам'яті будуть задоволені тільки що введеної сторінкою або вже існуючими в пам'яті сторінками, які були недавно використані. Точно такий же принцип дозволяє нам виключити і найменш використану page, з тією логікою, що те, що не було використано якийсь час, навряд чи буде використано і найближчим часом. Однак це не завжди так, і у виняткових випадках так, продуктивність може постраждати. Детальніше про це пізніше.

Рішення проблеми 4: тепер процеси можуть легко рости, якщо виникає проблема з простором, все, що потрібно, це зробити просту заміну page, що не переміщує будь-якої іншої процес.

Рішення проблеми 1: процес може отримати доступ до необмеженої пам'яті. Коли потрібно більше пам'яті, ніж доступно, диск використовується в якості резервної копії, нові необхідні дані завантажуються в пам'ять з диска, а найменш використаний frame даних (або page) переміщається на диск. Це може тривати нескінченно, а оскільки дисковий простір дешево і практично не обмежена, це створює ілюзію необмеженої пам'яті. Ще одна причина для назви Virtual Memory, це дає вам ілюзію пам'яті, яка насправді не доступна!

Здорово. Раніше ми стикалися з проблемою, коли хоча процес зменшується в розмірах, порожній простір важко утилізувати іншими процесами (оскільки це вимагало б дорогого ущільнення). Тепер легко, коли процес стає менше за розміром, багато його pages більше не використовуються, тому, коли іншим процесам потрібно більше пам'яті, просте виселення на основі LRU автоматично витісняє ці менш використовувані pages з ОЗУ і замінює їх нові сторінки з інших процесів (і, звичайно, оновлення page tables всіх цих процесів, а також вихідного процесу, який тепер вимагає менше місця), все це без будь-якої дорогої операції ущільнення!

Рішення проблеми 3: Всякий раз, коли процеси зменшуються в розмірі, їх frames в оперативній пам'яті будуть використовуватися рідше, тому просте виселення на основі LRU може виселити ці сторінки і замінити їх pages необхідними для нових процесів, що дозволить уникнути Internal Fragmentation без необхідності compaction.

Що стосується проблеми 2, знайдіть час, щоб зрозуміти це, сам сценарій повністю знищений! Немає необхідності переміщати процес, щоб пристосувати новий процес, тому що тепер весь процес ніколи не повинен відповідати відразу, тільки певні його сторінки повинні відповідати ad hoc, що відбувається шляхом видалення frames з ОЗУ. Все відбувається в одиницях pages, таким чином, тепер немає поняття hole, і, отже, не може бути й мови про те, що рухається! Може бути, довелося перемістити 10 pages через це нової вимоги, тисячі pages залишилися недоторканими. Беручи до уваги, що раніше, всі процеси (кожен біт) повинні були бути переміщені!

Рішення проблеми 2: Щоб пристосувати новий процес, дані з тільки що використовувалися останнім часом частин інших процесів повинні бути видалені в міру необхідності, і це відбувається в одиницях фіксованого розміру, які називаються pages. Таким чином, немає ніякої можливості hole або External Fragmentation з цією системою.

Тепер, коли процесу потрібно виконати деякі операції введення-виведення, він може легко звільнити процесор! ОС просто видаляє всі свої pages з ОЗУ (можливо, зберігає його в деякому кеші), в той час як нові процеси займають ОЗУ. Коли операція введення / виводу завершена, ОС просто відновлює ці pages в ОЗУ (звичайно, шляхом заміни pages з деяких інших процесів, може бути з тих, які замінили вихідний процес, або з тих, які самі повинні зробити I / O зараз і, отже , може відмовитися від пам'яті!)

Рішення проблеми 5. Коли процес виконує операції введення-виведення, він може легко відмовитися від використання ОЗУ, яке може використовуватися іншими процесами. Це призводить до правильного використання оперативної пам'яті.

І, звичайно ж, зараз жоден процес не має прямого доступу до оперативної пам'яті. Кожен процес звертається до розташування віртуальної пам'яті, яку будуть бачити фізичну адресу ОЗУ і підтримується page-table цього процесу. Відображення підтримується ОС, ОС дозволяє процесу дізнатися, який фрейм порожній, так що нова сторінка процесу може бути розміщена там. Оскільки це виділення пам'яті контролюється самої ОС, воно може легко гарантувати, що жоден процес не зазіхає на вміст іншого процесу, виділяючи тільки порожні кадри з ОЗУ або, зазіхаючи на вміст іншого процесу в ОЗУ, зв'язується з процесом. оновити його page-table.

Рішення вихідної проблеми: немає можливості доступу процесу до вмісту іншого процесу, так як весь розподіл управляється самої ОС, і кожен процес виконується в своєму власному ізольованому віртуальному адресному просторі.

Таким чином, paging (серед інших методів) в поєднанні з віртуальною пам'яттю - ось те, що забезпечує сьогодні програмне забезпечення, яке працює на ОС! Це звільняє розробника програмного забезпечення від занепокоєння про те, скільки пам'яті є на призначеному для користувача пристрої, де зберігати дані, як запобігти пошкодженню даних свого програмного забезпечення іншими процесами і т.д. Однак це, звичайно, не повна перевірка. Є недоліки:

1. Paging, в кінцевому рахунку, дає користувачеві ілюзію нескінченної пам'яті, використовуючи диск як вторинної резервної копії. Витяг даних з вторинного сховища для приміщення в пам'ять (це називається page swap, а подія, коли не вдається знайти потрібну сторінку в ОЗУ, називається page fault), є дорогим процесом, оскільки це операція введення-виведення. Це уповільнює процес. Кілька таких обмінів сторінок відбуваються послідовно, і процес стає болісно повільним. Ви коли-небудь бачили, щоб ваше програмне забезпечення працювало нормально і раптово, і раптом воно стало настільки повільним, що майже зависала, або не полишало вам можливості перезапустити його? Можливо, відбувалося занадто багато перестановок сторінок, що робило його повільним (так званий thrashing).

Отже, повертаючись до OP,

Навіщо нам потрібна віртуальна пам'ять для виконання процесу? - Як докладно пояснюється у відповіді, дати програмам ілюзію пристрої / ОС, що має нескінченну пам'ять, щоб можна було запускати будь-яке програмне забезпечення, велике або маленьке, не турбуючись про розподіл пам'яті або інших процесах, що ушкоджують свої дані, навіть коли працює паралельно. Це концепція, реалізована на практиці за допомогою різних методів, одним з яких, як описано тут, є пейджинг. Це також може бути сегментація.

Де знаходиться ця віртуальна пам'ять, коли процес (програма) з зовнішнього жорсткого диска переноситься в основну пам'ять (фізичну пам'ять) для виконання? - Віртуальна пам'ять ніде не варто сама по собі, це абстракція, завжди присутня, коли програмне забезпечення / процес / програма завантажується, для неї створюється нова таблиця сторінок, і вона містить відображення з адрес, виділених цим обробляти фактичний фізичну адресу в оперативній пам'яті. Оскільки адреси, що видаються процесом, не є реальними, в деякому сенсі вони фактично є, як ви можете сказати, the virtual memory.

Хто дбає про віртуальної пам'яті і який розмір віртуальної пам'яті? - Про це дбають, в тандемі, ОС та програмне забезпечення. Уявіть собі функцію у вашому коді (яка в кінцевому підсумку скомпільована і перетворена в виконуваний файл, який породив процес), яка містить локальну змінну - int i. Коли код виконується, i отримую адреса пам'яті в стеку функції. Ця функція сама зберігається як об'єкт десь ще. Ці адреси генеруються компілятором (компілятор, який компілював ваш код в виконуваний файл) - віртуальні адреси. При виконанні i повинен знаходитися десь в реальному фізичному адресу, по крайней мере, протягом цієї функції (якщо тільки вона не є статичною змінної!), Тому ОС відображає віртуальний адреса i згенерований компілятором, в фактичний фізичну адресу, так що всякий раз , коли Ця функція, деякий код вимагає значення i, цей процес може вимагати від ОС цей віртуальний адреса, а ОС, в свою чергу, може вимагати від фізичної адреси збережене значення і повернути його.

Припустимо, якщо розмір оперативної пам'яті складає 4 ГБ (тобто 2 ^ 32-1 адресних просторів), який розмір віртуальної пам'яті? - Розмір оперативної пам'яті не пов'язаний з розміром віртуальної пам'яті, він залежить від ОС. Наприклад, в 32-бітної Windows це 16 TB, в 64-бітної Windows 256 TB. Звичайно, він також може перевищувати обсягу диска, так як саме тут резервується пам'ять.