У сборщика мусора в Java есть одно серьёзное преимущество - не нужны hazard pointers для реализации Lock-free алгоритмов, т.к. не возникает ABA-проблемы за исключением редких случаев. Это актуально для архитектур типа x86_64, где нет LL/SC операций.
Для всего остального по всем параметрам лучше или memory-reuse, или детерминированное освобождение памяти через smart-pointers.

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)

ИзопропилGCjavaABAА как GC считает количество ссылок, он без счетчиков, по стеку каждого потока бегает?
бегает. и за процессорными регистрами следит
А есть возможность вызвать функцию принудительного сбора мусора?
И есть ли возможность (вручную указывать) заносить ссылки в разные сегменты сборщика мусора, чтобы очищать только заданные сегменты?

Dima TGCjavaABAА как GC считает количество ссылок, он без счетчиков, по стеку каждого потока бегает?
Глубоко не вникал, но как понимаю у GC нет необходимости знать сколько ссылок на объект, достаточно флага: есть ссылки/нет ссылок.

GCjavaABAиспользует медленные CAS-операции - ядро CPU замирает на 1000 тактов
Как вариант: две lock-free очереди , в одну пишем указатель на объект для увеличения счетчика, во вторую уменьшение и отдельный поток на разгребание этих очередей. Только у него доступ ко всем счетчикам. Тогда не надо никакой атомарности. Можно общую очередь сделать, писать туда указатель и флаг +/-. Правда при таком подходе теряем полноценный деструктор, т.к. все равно будет задержка и запуск в другом потоке.
"есть ссылки/нет ссылок" - кто-то этот флаг должен поставить, а этот кто-то как-то должен быть уверен, что больше ссылок нет в других потоках.

Да, выше у меня опечатка, shared_ptr использует не CAS in loop (lock-free), а RMW-операцию (wait-free).
Т.е. вместо одного wait-free (1000 тактов) счетчика использовать 2 lock-free очереди ( кол-во конкурентных потоков х 2 x 1000 тактов), в чем профит?