Консервативный сборщик мусора

Ответ 1

Сборщик мусора должен сканировать все объекты и вызовы (стеки исполнения), чтобы идентифицировать все "живые" адреса в исполняющей программе, а затем "собирать" объекты, у которых нет "живых" адресов. В некоторых средах возможно, чтобы алгоритм GC был ТОЧНО и точно знал, что такое адрес объекта, а что нет. В других средах он должен сканировать части хранилища (в первую очередь, стек выполнения), где есть слова хранилища, которые МОГУТ быть адресом объекта и делают предположение CONSERVATIVE, что если он выглядит как действительный адрес, и есть объект, который имеет адрес, то объект не должен собираться.

Есть преимущества консервативной коллекции, особенно в том, что генератор кода (если не интерпретируется) более свободен, чтобы выделять переменные где и когда он им нужен, и он не должен содержать строгий трек, который является указателем на объект. (Необходимость отслеживания местоположений указателей объектов может привести к менее хорошо оптимизированному коду, в дополнение к тому, что генератор кода будет значительно более сложным. Кроме того, консервативный сборщик имеет некоторые разумные шансы быть использованным с компилятором, который никогда не был предназначен для поддержки сборщик мусора, в то время как точный сборщик потребовал бы радикального изменения компилятора.)

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

Ответ 2

Консервативный сборщик мусора - это тот, который не знает, является ли данное слово указателем. Если слово указывает на выделенный блок кучи, сборщик мусора консервативно предполагает, что это слово является указателем и, следовательно, не перерабатывает этот блок кучи или что-либо, что считается доступным из него.

Основным преимуществом такого подхода является то, что он может собирать недостижимые значения без необходимости работать в согласии с компилятором. Однако есть много недостатков:

• Значения, которые выглядят как указатели, вызывают утечку памяти, предотвращая переработку части кучи. Это гораздо более сложная проблема с 32-разрядными адресными пространствами, потому что почти каждый int укажет на блок кучи, если выделены GB RAM.

• Определение того, указывает ли слово на выделенный блок кучи, требует, чтобы куча была обыскана, которая медленна и (объективно) не нужна.

• GC не может перемещать блоки кучи, поскольку он не может обновлять указатели, потому что он не знает, где они все.

• Код, который скрывает указатели или использует указатели вне кучного блока, приведет к сбою консервативного GC. Эта проблема возникла с помощью кода Numerical Recipes и GC Boehm, хотя, поскольку код NR C нарушил спецификацию C.

Эти недостатки достаточно серьезны, что сборщики мусора производственного процесса стараются не быть консервативными, когда это возможно.