Чи використовувати хеш-таблицю для збору сміття вирішить зупинити світову проблему розмітки та розміщення?

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

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

Чи є помилка в моїй думці?

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

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

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

Всі проблеми в інформатиці можуть бути вирішені іншим рівнем непрямості ... за винятком проблеми занадто багато шарів опосередкованості

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

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

while (true) {
    Object garbage = new Object();
}

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

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

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

Простір та економне захоплення об'єктів, зібраних сміттям

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

Специфікація віртуальної машини Java (1997)

Тож це спрацьовує, це було випробувано, а його неефективність призвела до розвитку систем генерації знаків та зачисток.