Чи є сміттєзбірники, які враховують підкачки?

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

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

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

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

memory-management paging garbage-collection

— Ян Рінроуз
джерело

Не точно підкачка, але рубінове корпоративне видання gc було переписане для зменшення ефекту gc на копію на сторінках запису, переміщуючи метадані об’єкта на окремі сторінки.

— користувач1937198

Дещо пов’язане запитання щодо malloc / вільних реалізацій: Чи будуть версії malloc повертати вільну пам'ять до системи? , особливо ця відповідь . Також: Чи безкоштовно () знімає пам'ять процесу?

— Пол А. Клейтон

дивно, але, здається, майже вся література (?) gc не аналізує підкачки ОС, окрім абстрактно. Ідея: система розподілу пам’яті, яка відслідковує покажчики між об’єктами у структурі, окремій від самих об’єктів, може бути більш локальною / пейджинговою, оскільки лише самі вказівники пересуваються (під час gc) у щільно ущільненому просторі замість усіх об’єктів різного розміру, який може бути розповсюджений в пам'яті (а деякі нечасто звертаються та знаходяться на сторінці). можуть бути невеликі накладні витрати, але це може допомогти заощадити в цілому залежно від впровадження.

— vzn

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

— supercat

Шаблон, який я використовував у тих випадках, коли елементи даних були малі відносно розміру моєї пам’яті, повинен містити, щоб кожен елемент даних складався із заголовка фіксованого розміру, який був призначений спереду, та даних змінного розміру, які б бути виділеними назад. У таблиці зберігаються відображені адреси логічного фрагмента до фізичних адрес та кількість вільного місця в кожному фрагменті; після кожного сканування він також визначив, скільки місця було мертвим. Посилання зберігалися у спалах, і кожна посилання мала форму "Пункт №3 логічного фрагмента №7". Цикл GC скопіював би всі живі дані з однієї частини до нової, і ...

— supercat

Відповіді:

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

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

Щодо питання в третьому пункті, яке було додане після того, як я відповів, колекція копій - це знову відповідь. ОС може зменшити кількість виділених фізичних сторінок під час збирання, оскільки сторінки повністю звільнені. З колекціонером відміток і розгортки, подія виходу на повну сторінку безкоштовно, мабуть, рідше, тому не варто враховувати конкретний маханізм.

Цей вид ідей природний і, ймовірно, описаний в деяких роботах. Але я не пам'ятаю це з рук. Я думаю, що ранні статті про Lisp GC містять деякі з цих ідей (наприклад: чи слід спочатку дотримуватися автомобіля чи компакт-диска?).

Хороша новина в цій ролі колекціонування копій також полягає в тому, що пейджинги дружать для копіювання колекції, оскільки це збільшує доступний простір для зберігання. Нагадаємо, що для збирання копій потрібно в принципі вдвічі більше місця, ніж використовується для фактичного зберігання даних. Тепер ефект підкачки залежить також від адресного простору машини та фізичної пам’яті. У старшому комп’ютері фізична пам’ять була набагато меншою, ніж доступний адресний простір, так що пейджингова підтримка була дійсно космічним бонусом, дозволяючи проводити такі політики, як копіювання GC. Навіть коли фізичний простір є таким же великим, як і адресний простір, можна поділитися ним, щоб процес, що використовує GC, мав менше адресного простору без підкачки (див. Підказка). Ці зауваження дещо витісняють використання колекцій поколінь. Вони, як правило, використовують колекцію копій для молодого покоління саме завдяки цим якостям і тому, що молоде покоління в основному недовговічне.

Тоді ви маєте всі взаємодії генераційних GC із системою кешу, про які йшлося в попередньому запитанні: Чи генератори збирачів сміття породжені кешами?

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

— бабу
джерело

я сумніваюся в ідеї, що колекціонери копії насправді є більш "локальними", ніж простежуючими. Колекціонери копій здаються концептуально досить схожими за динамікою доступу до пам’яті (можливо, майже невідрізною) відслідковуючи «старий простір». думаю, на це потрібна довідка. зазначає, що існує деяка можливість покращення механізму копіювання в новому просторі. новий простір починає ідеально суміжний, але потім ця "місцевість" з часом зменшується або деградує.

— vzn

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

— бабу

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

— vzn

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

— бабу

Вибачте ... переплутайте це питання з іншим ... у цьому є більше.

— babou

Емери Бергер, Метью Герц та І Фенг дещо працювали над цим.

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

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

Це відео розмови Емері про це, і він написав паперову колекцію сміття без пейджингу

З певних причин, здається, не буде набагато пізнішої роботи над цим чи будь-якого використання у реальному світі. В кінці статті написано: «Ми розробляємо паралельний варіант алгоритму збору закладок» , але я не можу його відстежити.

CRAMM: Підтримка віртуальної пам’яті для програм, зібраних зі сміттям, розглядає зміну ОС, щоб GC створювала менше підказок.

Використання резиденції сторінки для врівноваження компромісів у відстеженні сміття

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

— Ян Рінроуз
джерело