Dima TНа хабре статья вышла
про эволюцию сборщика мусора в Go
У меня вопрос появился: почему никто не развивает работу со счетчиками ссылок? Или как там оно правильно называется. По сути как смарт-указатели из С++. Еще WinAPI использует для работы с объектами ядра.
Технически реализация не сложная: присвоил ссылку на объект переменной сделал Счетчик++, освободил - Счетчик--. Получил 0, запустил деструктор.
Плюсы очевидны:
1. Объект уничтожается именно тогда, когда он стал не нужен, т.е. можно управлять этим процессом, не получая остановку проги сборщиком в самый напряженный момент.
2. Возможен полноценный деструктор, а не малоприменимое недоразумение в виде финализатора, который неизвестно когда будет вызван сборщиком мусора.
Минусы:
1. Постоянное изменение счетчика. Плюс надо атомарность соблюдать, т.к. сейчас все ЯП многопоточные.
2. Память под счетчик. 4 байта на объект может быть критично при большом количестве маленьких объектов.
По моему минусы не такие уж и серьезные. Но, как понимаю они перевешивают плюсы раз большинство ЯП используют сборку мусора.
Теоретически в любом ЯП со сборщиком мусора можно безболезненно заменить его на использование счетчиков ссылок, и это никак не потребует переписывания кода на этом ЯП, но никто не пытается. Интересно почему?
А как GC считает количество ссылок, он без счетчиков, по стеку каждого потока бегает?
Бывает 2 основных вида smart-pointers:
1. shared pointers (std::shared_ptr<>) - на каждый указатель по 1 атомарному счетчику ссылок (8 bytes), использует медленные CAS-операции - ядро CPU замирает на 1000 тактов
2. hazard pointers - на каждый указатель по ~1-4*threads дополнительных указателей (8-32 bytes per thread), использует быстрые MOV-операции, сильно быстрее для многопоточных программ и оптимизируются внеочередным исполнением на CPU
В ЯП с GC не пытаются переписать на указатели типа 1 (shared pointers) со счетчиком, т.к. без культуры использование общих между потоками указателей со счетчиком в многопоточной программе приведет к её замедлению.
Почему ЯП с GC не пытаются переписать на указатели типа 2 (hazard pointers)? Вот как раз GC примерно так и работает, за исключением того, что hazard pointers сборщик мусора управляемый и сегментированный:
- есть возможность детерминировано вручную запускать сборку мусора вызовом функции Scan()
- для каждого контейнера обычно создается свой сборщик мусора (своя структура hazard pointers)
