Як обмежені розміри стека та купи обмежені ОС?

Примітка : якщо вам потрібно розглянути конкретну ОС, щоб мати можливість відповідати, будь ласка, врахуйте Linux.

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

Питання 1 : чи мають стек та купа мають статичний ліміт розміру (наприклад, по 2 гігабайта кожен), чи цей ліміт динамічний, змінюючись відповідно до розподілу пам’яті під час виконання програми (тобто загалом 4 гігабайти, якими повинен користуватися обидва, так що якщо програма використовує тільки стек, вона зможе мати стек з 4 гігабайти)?

Питання 2 : Як визначається межа? Це загальна доступна оперативна пам’ять?

Питання 3 : Що з текстом (кодом) та розділами даних, як вони обмежені?

Є два різних обмеження пам'яті. Ліміт віртуальної пам'яті та обмеження фізичної пам'яті.

Віртуальна пам'ять

Віртуальна пам'ять обмежена розміром та компонуванням наявного адресного простору. Зазвичай на самому початку є виконуваним кодом та статичними даними та минулим, що збільшує купу, а в кінці - область, зарезервована ядром, перед нею - спільні бібліотеки та стеки (що на більшості платформ зростає). Це дає купі та стеку вільний простір для зростання, інші області відомі при запуску та фіксації.

Вільна віртуальна пам'ять спочатку не позначається як придатна для використання, але вона позначається такою під час розподілу. Хоча купа може розростатися до всієї доступної пам'яті, більшість систем не розростає стеки автоматично. Ліміт IIRC для стека - 8MiB в Linux та 1MiB в Windows і може бути змінений в обох системах. Віртуальна пам'ять також містить будь-які файли та обладнання з картографічною пам'яттю.

Однією з причин того, що стек не може бути автоматично вирощений (довільно), є те, що багатопотокові програми потребують окремого стека для кожного потоку, щоб вони врешті-решт потрапляли один у одного.

На 32-бітних платформах загальний обсяг віртуальної пам’яті становить 4GiB, і Linux, і Windows зазвичай резервують останній 1GiB для ядра, що дає вам максимум 3GiB адресного простору. Існує спеціальна версія Linux, яка не резервує нічого, даючи вам повний 4GiB. Це корисно для рідкісних випадків великих баз даних, де останній 1GiB економить день, але для регулярного використання він трохи повільніше через додаткові перезавантаження таблиць сторінок.

На 64-бітних платформах віртуальна пам'ять становить 64EiB, і вам не доведеться думати про це.

Фізична пам'ять

Фізична пам'ять зазвичай виділяється операційною системою лише тоді, коли процес потребує доступу до неї. Скільки фізичної пам’яті використовує процес - це дуже нечітке число, оскільки деяка пам’ять поділяється між процесами (код, спільні бібліотеки та будь-які інші відображені файли), дані з файлів завантажуються в пам'ять на вимогу та викидаються, коли є дефіцит пам’яті та "анонімна" пам'ять (та, яка не підтримується файлами) може бути замінена.

В Linux те, що станеться, коли у вас не вистачає фізичної пам'яті, залежить від vm.overcommit_memoryналаштування системи. За замовчуванням - перевиконання. Коли ви просите систему виділити пам'ять, вона дає вам деякі, а лише виділяє віртуальну пам'ять. Коли ви фактично отримуєте доступ до пам'яті, вона намагатиметься використовувати фізичну пам'ять, відкидаючи дані, які можна перечитати або замінити речі за необхідності. Якщо він виявить, що нічого не може звільнити, він просто видалить процес із існування (немає ніякого способу реагувати, оскільки ця реакція може зажадати більше пам'яті, а це призведе до нескінченного циклу).

Так вмирають процеси на Android (що також є Linux). Логіка була вдосконалена логікою, який процес видалити з існування, виходячи з того, що цей процес робить і скільки йому років. Тоді андроїдні процеси просто перестають робити що завгодно, але сидіти на задньому плані, і "вбивця пам'яті" вб'є їх, коли йому потрібна пам'ять для нових.

Я думаю, що простіше відповісти на це порядком того, як використовується пам'ять.

Питання 3: Що з текстом (кодом) та розділами даних, як вони обмежені? Текст і Дані готуються компілятором. Вимога компілятора - переконатися, що вони доступні, і упакувати їх у нижній частині адресного простору. Доступний адресний простір буде обмежений апаратним забезпеченням, наприклад, якщо реєстр покажчиків інструкцій є 32-розрядним, то простір текстової адреси буде 4 Гб.

Питання 2: Як визначається межа? Це загальна доступна оперативна пам’ять? Після тексту та даних, область над цією купою. З віртуальної пам'яттю, купа може практично рости вгору близько до максимального адресного простору.

Питання 1: чи мають стек та купа мають статичний ліміт розміру (наприклад, по 2 гігабайта кожен), чи цей ліміт динамічний, змінюючись відповідно до розподілу пам'яті під час виконання програми (тобто загалом 4 гігабайти, якими повинен користуватися обидва, так що якщо програма використовує тільки стек, вона зможе мати стек з 4 гігабайти)? Кінцевим сегментом у адресному просторі процесу є стек. Стек займає кінцевий сегмент адресного простору, і він починається з кінця і зростає вниз .

Оскільки купа росте, а стопка росте вниз, вони в основному обмежують один одного. Крім того, оскільки обидва типи сегментів можуть бути записані, не завжди було порушенням одного з них для переходу кордону, тому ви могли мати переповнення буфера або стека. Зараз є механізм, щоб не допустити їх.

Існує встановлений ліміт для купи (стека) для кожного процесу, з якого слід розпочати. Цей ліміт можна змінити під час виконання (використовуючи brk () / sbrk ()). В основному те, що відбувається, коли процесу потрібно більше купольного простору і у нього не вистачає виділеного простору, стандартна бібліотека видасть виклик ОС. ОС виділить сторінку, якою зазвичай керує бібліотека користувачів для використання програмою. Тобто, якщо програма хоче 1 KiB, ОС надасть додаткові 4 KiB, а бібліотека дасть програмі 1 KiB і залишиться 3 KiB для використання, коли програма наступного разу попросить більше.

Більшу частину часу макет буде "Текст", "Дані", "Купа" (зростає), нерозподілений простір і нарешті Стек (зростає вниз). Усі вони мають однаковий адресний простір.