Програмне забезпечення працює в ОС дуже простою умовою - їм потрібна пам'ять. ОС пристрою забезпечує його у вигляді ОЗУ. Об'єм необхідної пам'яті може змінюватися - деяким програмним забезпеченням потрібна величезна пам'ять, а деякі потребують малої пам'яті. Більшість користувачів (якщо не всі) користувачі одночасно запускають кілька додатків в ОС, і, враховуючи, що пам'ять дорога (а розмір пристрою - обмежений), обсяг пам'яті завжди обмежений. Оскільки, враховуючи, що всі програмні засоби потребують певної кількості оперативної пам’яті, і всі вони можуть бути зроблені одночасно, ОС має подбати про дві речі:
- Це програмне забезпечення завжди працює, поки користувач не перерве його, тобто він не повинен автоматично скасовувати, оскільки в ОС не вистачає пам'яті.
- Вищезазначена діяльність, зберігаючи привабливі показники для програмного забезпечення, що працює.
Тепер головне питання зводиться до того, як керується пам'яттю. Що саме визначає, де в пам'яті будуть знаходитися дані, що належать даному програмному забезпеченню?
Можливе рішення 1 : Нехай окремі програмні програми чітко вказують адресу пам'яті, яку вони використовуватимуть у пристрої. Припустимо, Photoshop заявляє, що він завжди буде використовувати адреси пам'яті, починаючи від 0- 1023(уявіть пам'ять як лінійний масив байтів, тому перший байт знаходиться в розташуванні 0, 1024а байт - у розташуванні 1023) - тобто займає 1 GBпам'ять. Точно так же, VLC заявляє , що вона буде займати область пам'яті 1244до 1876і т.д.
Переваги:
- Кожному додатку заздалегідь призначений слот для пам’яті, тому при його встановленні та виконанні він просто зберігає свої дані в цій області пам’яті, і все працює добре.
Недоліки:
Це не масштабується. Теоретично, додатку може знадобитися величезна кількість пам'яті, коли він робить щось дійсно важке. Щоб гарантувати, що у ніколи не залишається пам'ять, виділена для неї область пам’яті завжди повинна бути більше або дорівнює цій кількості пам’яті. Що робити, якщо програмне забезпечення, максимальне використання якого має теоретична пам'ять 2 GB(отже, вимагає 2 GBрозподілення пам'яті з оперативної пам’яті), встановлено на машині, що має лише 1 GBпам’ять? Чи повинно програмне забезпечення перерватись при запуску, сказавши, що доступна оперативна пам’ять менше, ніж 2 GB? Або це має продовжуватися, і в той момент, коли потрібна пам'ять перевищує 2 GB, просто перервіть і виправдайте повідомлення про те, що пам'яті недостатньо?
Не можна запобігти керуванню пам’яттю. Там є мільйони програмних засобів, навіть якщо кожному з них було виділено лише 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внизу є вільний простір:
Опера плавно вписується внизу. Тепер ваша ОЗУ виглядає так:
Добре. Все виглядає добре. Однак місця не залишилося багато, і тепер вам потрібно запустити Chrome знову, відому пам’ять! Для запуску потрібно багато пам’яті, а у вас ледь не залишилося… За винятком .. ви зараз помічаєте, що деякі процеси, які спочатку займали великий простір, зараз не потребують багато місця. Можливо, ви зупинили своє відео у VLC , отже, воно все ще займає трохи місця, але не стільки, скільки потрібно для запуску відео з високою роздільною здатністю. Аналогічно для блокнота та фотографій . Тепер ваша оперативна пам’ять виглядає приблизно так:
Holes, знову! Назад до квадратного! За винятком випадків, коли отвори виникали через процеси, що закінчуються, тепер це відбувається через процеси, що вимагають менше місця, ніж раніше! І ви знову маєте ту саму проблему, що holesкомбінований приносить більше місця, ніж потрібно, але вони розкидані навколо, не використовуючи окремо. Тож вам доведеться перенести ці процеси знову, дорога операція, і дуже часта при цьому, оскільки процеси часто зменшуються в розмірі протягом їхнього життя.
Проблема 3: Процеси впродовж їхнього життя можуть зменшуватися в розмірах, залишаючи позаду невикористаний простір, який, якщо потрібно використовувати, зажадає дорогої операції переміщення багатьох процесів. Це називається
Internal Fragmentation.
Чудово, тож тепер ваша ОС робить необхідне, переміщує процеси та запускає Chrome, а через деякий час ваша ОЗУ виглядає так:
Класно. Тепер припустимо, що ви знову відновите перегляд " Аватара" у VLC . Його вимога до пам’яті збільшиться! Але ... не залишається місця для його зростання, оскільки Блокнот стиснутий внизу. Отже, знову ж таки, всі процеси повинні рухатися нижче, поки VLC не знайде достатньо місця!
Проблема 4: Якщо процеси потребують зростання, це буде дуже дорогою операцією
Чудово. Тепер припустимо, що " Фото" використовується для завантаження деяких фотографій із зовнішнього жорсткого диска. Доступ до жорсткого диска переводить вас із сфери кеш-пам'яті та оперативної пам’яті до диска, який повільніше на порядки величин. Болісно, безповоротно, трансцендентально повільніше. Це операція вводу / виводу, що означає, що вона не пов'язана з процесором (це навпаки), а це означає, що їй зараз не потрібно займати оперативну пам'ять. Однак він все ще вперто займає оперативну пам’ять. Якщо ви хочете тим часом запустити Firefox , ви не можете, оскільки пам'яті не так багато, тоді як якщо фотографії витягнуті з пам’яті протягом тривалості її пов’язаної з I / O діяльності, це звільнило б багато пам’яті, з подальшим (дорогим) ущільненням, після чого встановлюється Firefox .
Проблема 5: Завдання, пов'язані з входом / виводом, продовжують займати оперативну пам’ять, що призводить до недостатнього використання оперативної пам'яті, яка тим часом могла використовуватися завданнями, пов'язаними з процесором.
Отже, як ми бачимо, у нас так багато проблем навіть із наближенням віртуальної пам’яті.
Для вирішення цих проблем є два підходи - pagingі segmentation. Давайте обговоримо paging. У цьому підході віртуальний адресний простір процесу відображається у фізичну пам'ять фрагментами - так називається pages. Типовий pageрозмір 4 kB. Відображення підтримується тим, що називається a 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заснований, коли кадр, до якого останнім часом можна було отримати доступ до процесу, може бути виселений. Це може бути first-come-first-evictedосновою, коли кадр, який виділявся найдовше, тому виселяється тощо) .) Отже, якийсь кадр виселений. Скажіть кадр 1 (просто випадковим чином вибираючи його). Однак frameце відображається на деякихpage! (В даний час вона відображається за допомогою таблиці сторінок на сторінці 3нашого єдиного процесу). Тож цей процес повинен бути повідомлений цією трагічною новиною, що ту frame, яка нещасна належить вам, потрібно виселити з ОЗУ, щоб звільнити місце для іншої pages. Процес повинен гарантувати, що він оновлює його page tableцією інформацією, тобто видаляючи запис для цього дуету кадру сторінок, щоб наступного разу, коли запит робиться для цього page, він правильно повідомляє процесу, що цього pageбільше немає в пам'яті , і має бути завантажений з диска. Добре. Таким чином кадр 1виселяється, сторінка 0вводиться і розміщується там в оперативній пам’яті, а запис для сторінки 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 / О тепер, а значить, можна відмовитися від пам’яті!)
Рішення проблеми 5: Коли процес виконує операції вводу / виводу, він може легко відмовитися від використання оперативної пам'яті, що може бути використане іншими процесами. Це призводить до правильного використання оперативної пам’яті.
І звичайно, зараз жоден процес не має прямого доступу до ОЗУ. Кожен процес отримує доступ до місця віртуальної пам'яті, яке відображається на фізичну адресу RAM та підтримується page-tableцим процесом. Відображення підтримується ОС, ОС дозволяє процесу знати, який кадр порожній, щоб там могла бути розміщена нова сторінка процесу. Оскільки за цим розподілом пам’яті керує сама ОС, вона може легко переконатись, що жоден процес не посягає на вміст іншого процесу, виділяючи лише порожні кадри з оперативної пам’яті або зазіхаючи на вміст іншого процесу в оперативній пам’яті, передає процес оновити його page-table.
Рішення оригінальної проблеми: Немає можливості процесу отримати доступ до вмісту іншого процесу, оскільки всім розподілом керує сама ОС, а кожен процес працює у власному пісочному віртуальному просторі адрес.
Отже paging(серед інших методик) у поєднанні з віртуальною пам’яттю - це те, що діє сьогодні на програмне забезпечення, що працює на ОС! Це звільняє розробника програмного забезпечення від занепокоєння щодо того, скільки пам’яті доступно на пристрої користувача, де зберігати дані, як запобігти іншим процесам зіпсування даних програмного забезпечення тощо. Однак це, звичайно, не є надійним. Є вади:
Pagingце, в кінцевому рахунку, надання користувачеві ілюзії нескінченної пам'яті, використовуючи диск як вторинну резервну копію. Отримання даних із вторинної пам’яті для вписання в пам’ять (викликається page swap, і виклик події не знаходження потрібної сторінки в оперативній пам’яті page fault) є дорогим, оскільки це операція вводу-виводу. Це уповільнює процес. Кілька таких замінів сторінок відбуваються поспіль, і процес стає болісно повільним. Ви коли-небудь бачили, щоб ваше програмне забезпечення працювало чудово та денді, і раптом воно стає настільки повільним, що майже зависає, або не залишає у вас жодного варіанту, щоб перезапустити його? Можливо, занадто багато підкачань сторінок відбувалося, що робить його повільним (називається thrashing).
Тож повертаючись до ОП,
Навіщо нам потрібна віртуальна пам'ять для виконання процесу? - Як пояснюється у відповіді довго, надавати програмному забезпеченню ілюзію, що пристрій / ОС має нескінченну пам’ять, так що будь-яке програмне забезпечення, велике чи мале, можна запускати, не турбуючись про розподіл пам’яті чи інші процеси, що пошкоджують його дані, навіть коли працює паралельно. Це концепція, реалізована на практиці за допомогою різних методик, однією з яких, як описано тут, є Пейджинг . Це також може бути сегментація .
Де стоїть ця віртуальна пам'ять, коли процес (програма) із зовнішнього жорсткого диска підводиться до основної пам'яті (фізичної пам'яті) для виконання? - Віртуальна пам'ять сама по собі не стоїть ніде, це абстракція, завжди присутня, коли завантажується програмне забезпечення / процес / програма, для неї створюється нова таблиця сторінок, і вона містить відображення з адрес, виплетених цим обробляти до фактичної фізичної адреси в оперативній пам'яті. Так як адреса сплюнув в процесі не реальні адреси, в якому - то сенсі, вони, на самому ділі, що ви можете сказати, the virtual memory.
Хто піклується про віртуальну пам’ять і який розмір віртуальної пам'яті? - Про це дбають, в тандемі, ОС і програмне забезпечення. Уявіть у своєму коді функцію (яка в підсумку компілюється і перетворюється у виконуваний файл, що породив процес), який містить локальну змінну - an int i. Коли код виконується, iотримує адресу пам'яті в межах стека функції. Ця функція сама зберігається як об'єкт десь в іншому місці. Ці адреси генеруються компілятором (компілятор, який склав ваш код у виконуваний файл) - віртуальні адреси. Коли він виконаний, iвін повинен перебувати десь у фактичній фізичній адресі протягом тривалості цієї функції, принаймні (якщо це не статична змінна!), Тому ОС відображає компілятор, генерований віртуальну адресуiна фактичну фізичну адресу, так що коли-небудь у межах цієї функції деякий код вимагає значення i, цей процес може запитувати ОС для цієї віртуальної адреси, а ОС, в свою чергу, може запитувати фізичну адресу на збережене значення та повертати його.
Припустимо, якщо розмір оперативної пам’яті становить 4 Гб (тобто 2 ^ 32-1 адресний простір), який розмір віртуальної пам’яті? - Розмір оперативної пам’яті не пов'язаний з розміром віртуальної пам’яті, це залежить від ОС. Наприклад, у 32-розрядних Windows, це 16 TBна 64-бітних Windows 256 TB. Звичайно, він також обмежений розміром диска, оскільки саме там зберігається резервна пам'ять.