Gc используя информацию о типе

Question

Кто-нибудь знает алгоритм GC, который использует информацию о типе, чтобы разрешить инкрементный сбор, оптимизированный сбор, параллельный сбор или какую-либо другую полезную функцию?

Под информацией о типе я подразумеваю реальную семантику.Позвольте мне привести пример: предположим, у нас есть класс стиля OO с методами для поддержки списка, который скрывает представление.Когда объект становится недоступным, сборщик может просто запустить список, удалив все узлы.Он знает, что все они сейчас недоступны из-за инкапсуляции.Он также знает, что нет необходимости выполнять общее сканирование узлов на наличие указателей, поскольку он знает, что все узлы имеют одинаковый тип.

Очевидно, что это особый случай, который легко обрабатывается деструкторами в C ++.Реальный вопрос заключается в том, есть ли способ проанализировать типы, используемые в программе, и дать указание сборщику использовать полученную информацию с пользой.Полагаю, вы бы назвали этот сборщик мусора типа .

Answer 1

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

Вот несколько ссылок.Один из них предназначен для обнаружения утечек, а другой (из моей исследовательской группы) - об улучшении локальности кэша.список литературы для сбора мусора для получения дополнительных ссылок, или спросите людей в gc-list .

Answer 2

Я не думаю, что это имеет какое-либо отношение к определенному алгоритму.

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

Независимо от выбранного алгоритма GC: информация больше зависит от того, как компилятор / среда выполнения извлечет эту информацию.

Кроме того, я бы избегал C и C ++ с GC. Из-за арифметики указателей, псевдонимов и возможности указывать внутри объекта (ссылка на элемент данных или в массиве), невероятно сложно выполнить точную сборку мусора на этих языках. Они не были созданы для этого.