Коли збирач сміття ущільнює предмети в купі, чи змінює він посилання на стеку?

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

Моє запитання таке: коли збирач сміття ущільнює об’єкти в купі, як поновлюються посилання на ці об’єкти в стеці? Я можу придумати два можливі рішення:

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

Чи використовують сміттєзбірники переважно один із цих двох методів? Якийсь інший метод? Обидва?

garbage-collection

— todorojo
джерело

Дивіться stackoverflow.com/questions/3799203/… та en.wikipedia.org/wiki/…

— Gort the Robot

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

— todorojo

Термін для речі, про яку ви говорите, - "переміщення сміттєзбірника". Я відверто не знаю, наскільки вони часто використовуються.

— Gort the Robot

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

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

Підхід до таблиці пошуку в принципі може працювати. Однак, щоб зробити всі доступні покажчики потрібно зробити 2 кроки. Це може мати величезний вплив на продуктивність на нормальний час роботи. Зокрема для випадку використання багатьох дрібних предметів. (Це випадок, коли найсучасніші програми GC зазвичай переважають підрахунок еталонів.)

— btilly
джерело

Я додам, що я думаю, що GC, ймовірно, намагається не переміщувати речі на купі, якщо не потрібно. У сучасному мультипроцесорному світі це повинен бути кошмар синхронізації, коли їм потрібно оновити всі посилання на щось на купі, поки працює програма, яка використовує ці посилання. Таблиця пошуку спростить це, але я думаю, що це виняток, а не норма, тому більшості GC, мабуть, доведеться заблокувати деякі посилання, перемістити пам'ять, а потім оновити посилання. +1 Цікаве запитання, +1 хороша відповідь.

— GlenPeterson

@GlenPeterson Багато GC дійсно не переміщують речі на купу і не стикаються з цією проблемою. Але ущільнюючий GC за визначенням переміщує живі об'єкти навколо, щоб дефрагментувати пам'ять.

— btilly

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

— Джиммі Хоффа

Оригінальні Macintosh та Palm OS використовували підхід таблиці пошуку для управління пам’яттю. Покажчики в таблиці називали ручками. Переміщаючий GC повинен знати місце розташування абсолютно позитивно кожної посилання на будь-який об'єкт, на який він рухається; використання єдиної таблиці для таких цілей значно спрощує речі.

— supercat