Недоліки керованої оперативної пам'яті

Мені дуже подобається управління пам’яттю на основі сфери (SBMM) або RAII , як це частіше (заплутано?) Посилається на спільноту C ++. Наскільки я знаю, крім C ++ (і C), немає жодної іншої мови, яка використовується сьогодні, що робить SBMM / RAII їх основним механізмом управління пам'яттю, а натомість вони вважають за краще використовувати сміття (GC).

Я вважаю це досить заплутаним, оскільки

1. SBMM робить програми більш детермінованими (ви можете точно сказати, коли об’єкт знищений);
2. у мовах, які використовують GC, вам часто доводиться вручну керувати ресурсами (див., наприклад, закриття файлів на Java), що частково перешкоджає призначенню GC, а також є схильними до помилок;
3. Купі пам'ять також може бути (дуже елегантно, imo) обмежена сферою дії (див. std::shared_ptrу C ++).

Чому SBMM не використовується ширше? Які його недоліки?

Почнемо з постулювання, що пам'ять на сьогоднішній день (десятки, сотні чи навіть тисячі разів) частіше, ніж усі інші ресурси разом. Кожна окрема змінна, об’єкт, член об'єкта потребує виділеної йому пам'яті та звільненої пізніше. Для кожного відкритого файлу ви створюєте десятки до мільйонів об'єктів для зберігання даних, витягнутих з файлу. Кожен потік TCP поєднується з необмеженою кількістю тимчасових байтових рядків, створених для запису в потік. Ми тут на одній сторінці? Чудово.

Щоб RAII працював (навіть якщо у вас є готові розумні покажчики для кожного випадку використання під сонцем), вам потрібно отримати право власності . Вам потрібно проаналізувати, хто повинен володіти тим чи іншим об’єктом, хто не повинен, і коли право власності має бути передано з А на Б. Зрозуміло, ви можете використовувати спільну власність на все , але тоді ви будете емулювати GC за допомогою розумних покажчиків. З цього моменту стає набагато простіше та швидше побудувати GC на мові.

Збір сміття звільняє вас від турботи про далеко не найчастіше використовуваний ресурс, пам’ять. Звичайно, все ж потрібно прийняти те саме рішення для інших ресурсів, але вони набагато рідше (див. Вище), і складні (наприклад, спільне) володіння також рідше. Психічне навантаження значно знижується.

Тепер ви називаєте деякі недоліки у тому, щоб усі цінності збирали сміття. Однак інтегрувати як безпечний для пам'яті GC, так і типи значень з RAII в одну мову вкрай складно, тож, можливо, краще змінити ці компроміси іншими способами?

Втрата детермінізму виявляється не такою поганою на практиці, оскільки впливає лише на детермінований термін експлуатації об'єкта . Як описано в наступному параграфі, більшість ресурсів (окрім пам’яті, яка є достатньою і може бути ліниво перероблена), не пов'язана з усіма ресурсами цих мов. Є кілька інших випадків використання, але вони є рідкісними в моєму досвіді.

Ваш другий пункт, ручне управління ресурсами, сьогодні вирішується за допомогою заяви, яка виконує очищення, засноване на масштабах, але не прив'язує це очищення до часу життя об'єкта (отже, не взаємодіючи з GC та безпекою пам'яті). Це usingв C #, withв Python, try-з ресурсами в останніх версіях Java.

RAII також випливає з автоматичного управління пам'яттю підрахунку посилань, наприклад, як використовується Perl. Хоча підрахунок посилань простий у здійсненні, детермінований та досить ефективний, він не може мати справу з циркулярними посиланнями (вони спричиняють витік), тому його не використовують.

Мови, зібрані сміттям, не можуть використовувати RAII безпосередньо, але часто пропонують синтаксис з аналогічним ефектом. У Java у нас є оператор "спробувати рессурси"

try (BufferedReader br = new BufferedReader(new FileReader(path))) { ... }

який автоматично викликає .close()ресурс при виході з блоку. У C # є IDisposableінтерфейс, який дозволяє .Dispose()викликати, залишаючи using (...) { ... }заяву. У Python є withтвердження:

with open(filename) as f:
    ...

яка працює аналогічно. Завдяки цікавій проблемі, метод відкритого файлу Ruby отримує зворотний виклик. Після виконання зворотного дзвінка файл закривається.

File.open(name, mode) do |f|
    ...
end

Я думаю, що Node.js використовує ту саму стратегію.

На мою думку, найбільш переконлива перевага сміттєзбірника полягає в тому, що він забезпечує можливість комбінованості . Коректність управління пам’яттю є місцевою властивістю в середовищі, що збирається сміттям. Ви можете переглянути кожну частину окремо і визначити, чи може вона просочитися пам’яттю. Комбінуйте будь-яку кількість запам’ятовуваних частин пам'яті, і вони залишаються правильними.

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

Це дуже помітно впливає на розробку програм різними мовами. Програми в GC-мовах, як правило, трохи більше супів об'єктів з великою кількістю взаємодій, тоді як у мовах, що не містять GC, більше віддають перевагу структурованим частинам із суворо контрольованою та обмеженою взаємодією між ними.

Закриття є важливою особливістю майже всіх сучасних мов. Їх дуже просто реалізувати за допомогою GC і дуже важко (хоча і не неможливо) отримати правильний результат з RAII, оскільки одна з головних їх особливостей полягає в тому, що вони дозволяють абстрагуватися протягом усього життя змінних!

C ++ отримав їх лише через 40 років після того, як всі інші зробили, і для того, щоб їх правильно виправити, потрібно було багато важкої роботи. На відміну від багатьох мов сценаріїв, розроблених та впроваджених людьми з нульовими знаннями в розробці та реалізації мов програмування, є їх.

1. SBMM робить програми більш детермінованими (ви можете точно сказати, коли об’єкт знищений);

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

2. у мовах, які використовують GC, вам часто доводиться вручну керувати ресурсами (див., наприклад, закриття файлів на Java), що частково перешкоджає призначенню GC, а також є схильними до помилок;

Дивіться usingв C # і useF #.

3. Купа пам’яті також може (дуже елегантно, imo) бути обмеженою сферою (див. std :: shared_ptr в C ++).

Іншими словами, ви можете взяти купу, яка є загальним рішенням, і змінити її на роботу лише в конкретному випадку, який серйозно обмежує. Це правда, звичайно, але марно.

Чому SBMM не використовується ширше? Які його недоліки?

SBMM обмежує те, що ви можете зробити:

1. SBMM створює проблему висхідного фінансування з першокласними лексичними закриттями, тому закриття є популярним і простим у використанні на таких мовах, як C #, але рідкісне і складне в C ++. Зауважимо, що існує загальна тенденція до використання функціональних конструкцій у програмуванні.

2. SBMM вимагає деструкторів, і вони перешкоджають виклику хвостів, додаючи більше роботи, перш ніж функція може повернутися. Хвостові дзвінки корисні для машин, що розширюються, і надаються такими речами, як .NET.

3. Деякі структури даних та алгоритми, як відомо, важко реалізувати за допомогою SBMM. В основному де завгодно, що цикли відбуваються в природі. Найбільше графічних алгоритмів. Ви фактично закінчуєте писати свій власний GC.

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

5. SBMM зберігає об’єкти живими до кінця їх сфери дії у вихідному коді, який часто довший необхідного і може бути набагато довшим, ніж потрібно. Це збільшує кількість плаваючого сміття (недоступних об’єктів, які чекають переробки). На противагу цьому, відстеження сміття, як правило, звільняє об'єкти незабаром після зникнення останнього посилання на них, що може бути набагато швидше. Дивіться міфи про управління пам'яттю: оперативність .

SBMM настільки обмежує, що програмістам потрібен маршрут евакуації в ситуаціях, коли життя не може бути здійснено до гніздування. У програмі C ++ shared_ptrпропонується шлях втечі, але це може бути на 10 разів повільніше, ніж відстеження сміття . Тож використання SBMM замість GC спричиняло б більшість людей неправильно. Однак це не означає, що це марно. SBMM як і раніше є цінним у контексті систем та вбудованих програм, де ресурси обмежені.

FWIW, можливо, ви хочете перевірити Форта та Ада і прочитати твір Ніколя Вірта.

Дивлячись на якийсь індекс популярності на зразок TIOBE (який, звичайно, є спірним, але, мабуть, для вашого типу питань його нормально використовувати), ви спочатку бачите, що ~ 50% перших 20 - це "мови сценаріїв" або "діалекти SQL" ", де" простота використання "та засоби абстракції мають набагато більше значення, ніж детермінована поведінка. З решти "складених" мов залишилося близько 50% мов із SBMM і ~ 50% без. Тож, виймаючи мови мовлення сценаріїв з вашого розрахунку, я б сказав, що ваше припущення просто неправильне, серед мов, що складаються, ті, які мають SBMM, такі ж популярні, як і без них.

Однією з головних переваг системи GC, про яку ще ніхто не згадував, є те, що посилання в системі GC гарантовано зберігає свою ідентичність до тих пір, поки вона існує . Якщо хтось викликає IDisposable.Dispose(.NET) або AutoCloseable.Close(Java) на об'єкті, коли існують копії посилання, ці копії продовжуватимуть посилатися на той самий об’єкт. Об'єкт більше не буде корисним, але спроби його використовувати матимуть передбачувану поведінку, керовану самим об'єктом. Навпаки, в C ++, якщо код викликає deleteоб’єкт і пізніше намагається його використовувати, весь стан системи стає абсолютно невизначеним.

Ще одна важлива річ, яку слід зазначити, це те, що управління пам’яттю на основі масштабів працює дуже добре для об’єктів з чітко визначеною власністю. Він працює набагато менше, а іноді і прямо погано, з об'єктами, які не мають визначеного права власності. Взагалі, об'єкти, що змінюються, повинні мати власників, тоді як незмінні об’єкти не потребують, але є зморшки: для коду дуже часто застосовувати екземпляр змінних типів для зберігання змінних даних, гарантуючи, що жодна посилання не буде піддаватися впливу код, який може вимкнути екземпляр. У такому сценарії екземпляри класу, що змінюється, можуть бути розподілені між декількома незмінними об'єктами і, таким чином, не мати чіткого права власності.

По-перше, дуже важливо усвідомити, що прирівнюють RAII до SBMM. або навіть до СБРМ. Однією з найважливіших (і найменш відомих або найбільш недооцінених) якостей RAII є той факт, що він робить «бути ресурсом» властивістю, яка НЕ ​​переходить до складу.

Наступна публікація в блозі обговорює цей важливий аспект RAII і протиставляє його ресурсозбереженню на мовах GCed, які використовують недетерміновані GC.

http://minorfs.wordpress.com/2011/04/29/why-garbage-collection-is-anti-productive/

Важливо зазначити, що в той час, як RAII використовується в основному в C ++, Python (нарешті, версія, що не заснована на ВМ) має деструктори та детерміновані GC, що дозволяє використовувати RAII разом із GC. Краще з обох світів, якби воно було.