Решит ли использование хеш-таблицы в сборщике мусора проблему мировой маркировки и очистки?

В алгоритме сборки мусора mark-sweep-compact вы должны останавливать мир при перемещении объектов, потому что ссылочный граф становится непоследовательным, и вы должны заменить значения всех ссылок, указывающих на объект.

Но что если бы у вас была хеш-таблица с идентификатором объекта в качестве ключа и указателем в качестве значения, а ссылки указывали бы на указанный идентификатор вместо адреса объекта ... тогда для исправления ссылок потребуется изменить только одно значение, а пауза потребуется только в том случае, если объект пытается быть записан во время копирования ...

Есть ли ошибка в моей мысли?

Обновление ссылок - не единственное, что требует паузы. Все стандартные алгоритмы, обычно сгруппированные в «mark-sweep», предполагают, что весь граф объекта остается неизменным, пока он помечен. Для правильной обработки изменений (новые объекты созданы, ссылки изменены) требуются довольно сложные альтернативные алгоритмы, такие как трехцветный алгоритм. Общий термин «параллельная сборка мусора».

Но да, обновление ссылок после сжатия также требует паузы. И да, использование косвенного обращения (например, с помощью постоянного идентификатора объекта и хеш-таблицы к реальным указателям) может значительно уменьшить количество пауз. Может быть даже возможно сделать эту часть без блокировки, если кто-то этого желает. Было бы так же сложно получить право, как и любой параллельный параллельный доступ к общей памяти, но нет фундаментальной причины, по которой это не сработало бы.

Однако это будет иметь серьезные недостатки. Помимо того, что занимает дополнительное место ( как минимум два лишних слова для всех объектов), это делает каждую разыменование намного дороже. Даже такая простая вещь, как получение атрибута, теперь включает в себя полный поиск по хеш-таблице. Я бы оценил снижение производительности как гораздо худшее, чем при инкрементной трассировке.

Все проблемы в информатике могут быть решены с помощью другого уровня косвенности ... за исключением проблемы слишком большого количества уровней косвенности

Ваш подход не сразу решает проблему сбора мусора, а только перемещает ее на один уровень вверх. И какой ценой! Теперь каждый доступ к памяти проходит через разыменование другого указателя. Мы не можем кэшировать местоположение результата, потому что оно могло быть перемещено в это время, мы всегда должны проходить через идентификатор объекта. В большинстве систем это косвенное обращение недопустимо, и предполагается, что остановка мира будет иметь более низкие общие затраты времени выполнения.

Я сказал, что ваше предложение только перемещает проблему, но не решает ее. Проблема заключается в повторном использовании идентификаторов объектов. Идентификаторы объектов теперь являются нашими эквивалентами указателей, а количество адресов ограничено. Возможно (особенно в 32-битной системе), что за время жизни вашей программы будет создано больше объектов INT_MAX, например, в цикле, подобном

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

Если мы просто увеличиваем ID объекта для каждого объекта, в какой-то момент у нас закончатся ID. Поэтому мы должны выяснить, какие идентификаторы все еще используются, а какие бесплатны, чтобы их можно было вернуть. Звучит знакомо? Теперь мы вернулись на круги своя.

В вашей мысли нет ошибки, вы только что описали нечто очень близкое к тому, как работал оригинальный сборщик мусора Java

Исходная виртуальная машина Java [6] и некоторые виртуальные машины Smalltalk используют косвенные указатели, называемые дескрипторами в [6], для ссылки на объекты. Дескрипторы позволяют легко перемещать объекты во время сборки мусора, поскольку с помощью дескрипторов имеется только один прямой указатель на каждый объект: один в его дескрипторе. Все остальные ссылки на объект непрямы через хандл. В таких системах памяти, основанных на дескрипторах, в то время как адреса объектов меняются в течение времени жизни объектов и поэтому не могут использоваться для хеширования, адреса дескрипторов остаются постоянными.

Пространственное и временное хеширование объектов, собранных мусором

В текущей реализации Sun виртуальной машины Java ссылка на экземпляр класса представляет собой указатель на дескриптор, который сам является парой указателей: один на таблицу, содержащую методы объекта, и указатель на объект Class, который представляет тип объекта, а другой - память, выделенная из кучи Java для данных объекта.

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

Так что это работает, это было опробовано, и его неэффективность привела к разработке систем меток и разверток поколений.