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


22

Я щойно зрозумів, що я припускаю, що відповідь на моє питання "так", але у мене немає вагомих причин. Я вважаю , що , можливо , є збирач сміття , який доказово вводить тільки найгірший спад. Чи є остаточне посилання, яке я можу навести? У моєму випадку я працюю над суто функціональною структурою даних і використовую Standard ML, якщо ці деталі мають значення.O(1)

І, можливо, це питання буде ще більш актуальним, коли він застосовується до структур даних, визначених, скажімо, на Java? Можливо, є якісь відповідні дискусії в підручниках з алгоритмів / структури даних, які використовують Java? (Я знаю, що у Sedgewick є версія Java, але я маю доступ лише до версії C.)

Відповіді:


17

Так, gc амортизується постійним часом. Припустимо, у вас є алгоритм, який працює за час з піковим робочим набором розміром k . Тепер зауважте, що ви можете виділити не більше O ( n ) слів під час виконання програми, і що часова вартість запуску копіювального сміттєзбірника становить O ( k ) (тобто вартість gc пропорційна загальній кількість живих даних). Отже, якщо ви запускаєте gc максимум O ( n / k ) разів, то загальна вартість виконання обмежується O ( n )nkO(n)O(k)O(n/k)O(n), що означає, що амортизована вартість gc є постійною. Отже, якщо у вас є колектор у стилі Чейні, при цьому кожна півпростора має розмір , то легко помітити, що повну колекцію не можна викликати більше одного разу кожні n / k кроки, оскільки виділення k слів займає O ( k ) час, і робочий набір ніколи не перевищує розмір k , що дає вам необхідну межу. Це виправдовує ігнорування проблем із gc.2kn/kkO(k)k

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

EDIT: Якщо ви хочете не амортизовані межі, колектор Cheney не зробить цього - він сканує весь набір живих кожного разу, коли його викликають. Ключовим словом для Google є "збирання сміття в реальному часі", і Djikstra та ін. і Стіл дав перші колекціонери для реального часу в реальному часі, а Бейкер дав перший ущільнення в реальному часі gc.

@article {dijkstra1978fly,
  title = {{Полезний збір сміття: Вправа у співпраці}},
  author = {Dijkstra, EW та Lamport, L. and Martin, AJ and Scholten, CS та Steffens, EFM},
  journal = {Зв'язок ОСББ},
  том = {21},
  число = {11},
  сторінки = {966--975},
  issn = {0001-0782},
  рік = {1978},
  Publisher = {ACM}
}

@article {steele1975multiprocessing,
  title = {{Багатопроцесорний компактний збір сміття}},
  автор = {Steele Jr, GL},
  journal = {Зв'язок ОСББ},
  том = {18},
  число = {9},
  сторінки = {495--508},
  issn = {0001-0782},
  рік = {1975},
  Publisher = {ACM}
}

@article {baker1978list,
  title = {{Обробка списку в режимі реального часу на послідовному комп'ютері}},
  автор = {Бейкер-молодший, HG},
  journal = {Зв'язок ОСББ},
  том = {21},
  число = {4},
  сторінки = {280--294},
  issn = {0001-0782},
  рік = {1978},
  Publisher = {ACM}
}

abab

1
"Так, gc амортизується постійним часом". Це взагалі не вірно. Ви можете стверджувати, що GC може бути, але це не обов'язково, а реальні, безумовно, ні. Наприклад, наївна List.mapв OCaml насправді є квадратичною складністю, оскільки глибина штабелю лінійна і стек проходить кожен раз, коли дитяча евакуйована. Те ж саме стосується основних фрагментів, що зустрічаються з великими масивами покажчиків.
Джон Харроп

12

O(n)

O(1)

Остаточним посиланням на збирання сміття є:

  • Збір сміття Річарда Джонса та Рафаеля Ліна

Бен Зорн провів деяку роботу, вимірюючи фактичні витрати на різні алгоритми вивезення сміття, хоча поданий нижче останній документ представляє набагато більш повне порівняння:

  • Міфи та реалії: Вплив на збирання сміття , С. М. Блекберн, П. Ченг та К. С. Маккінлі, конференція ACM SIGMETRICS з питань вимірювання та моделювання комп'ютерних систем, стор. 25--36, Нью-Йорк, Нью-Йорк, червень 2004 року.

Докладніше див:

  • Уніфікована теорія збору сміття , Бекон, Ченг і Раджан, Конференція ACM з об'єктно-орієнтованого програмування, систем, мов та застосувань, Ванкувер, BC, Канада, стор. 50-68, 2004.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.