и что там в java и go делают? я смотрел доклады про gc все они работают по принципу сканирования ссылок и удаления недоступных объектов. Да, есть куча оптимизаций, можно сделать многопоточный сборщик, можно по разному разбивать на поколения и пытаться сколько угодно инкрементально собирать но объем работы не изменится - из-за принципа что удаление объектов происходит через проход/сканирование по графу доступных объектов (потом очистки недоступных) у нас тут прямая связь с количеством объектов в памяти и сложность O(n). Или может я ошибаюсь и есть сборщики мусора которые работают не через сканирование и время их работы не зависит от количества объектов?

я так полагаю дихотомия: GC vs. manual MM? В таком случае удаление N "обектов" тоже O(n)

Посмотрите на Immix GC. Он даст фору даже лайфтаймам. Начнем с того, что там используется некий аналог зон / bump аллокаторов, то есть уже нет malloc / free а простанство переиспользуется.

второе лайфтаймы в большинстве случаем покрывабтся scalar replacment и объекты вообще не попадат в кучу так как все лежит на стеке

проблема GC совершенно не в сканировании, а в latency и оптимальных эвристиках когда и где начинать сканирование)

тебя троллят , не заводись с пол оборота ЛОЛ. Пусть пишет без GC на здоровье

Не, здесь другое)

а это разве сильно отличается от обычных аллокаторов?

(если что, я про Immix вообще ничего не знаю)

Но рано или поздно все равно ведь нужно просканировать и старое поколение? Суть бд в оперативке в том что там в куче находятся миллиарды объектов. И кстати для такой бд сборщик мусора собственно и не нужен, так как всегда явно определяется когда нужно удалять объекты - неважно сколько их в памяти (например 50 млд объектов которые занимают 4тб) - апи бд всегда явное - создать/обновить/удалить такой-то объект из таблицы. База данных уже знает какие другие объекты ссылаются на этот объект потому что и так занимается индексированием. То есть все что мне нужно так это способ явного удаления объекта из памяти.
Только почему-то языки с gc включая java/go/javascript похоже считают что не нужно давать программисту явно удалять объекты. Тут либо возиться с week-ссылками (я правда не знаю какой у них оверхед и будет ли это работать на терабайтах оперативки) либо пилить свои объекты если хранить все данные в числовом массиве (но например в трекере v8 уже 5 лет висит ишью о невозможности аллоцировать массив больше 4гб)

на сколько я понимаю преимущество gc над подсчетом ссылок в том что gc умеет разруливать циклические зависимости

Immix’s fine-grained heap organization with copying is an excellent match for conservative garbage collection. Most objects are allocated contiguously into 32 KB blocks, and can be copied upon survival. Conservative Immix pins the target objects of ambiguous references at the granularity of 256 B lines. The size of contiguous allocation regions and the associated potential for better locality is thus increased by a factor of eight over MCC, which pins at a page granularity. The  granularity of pinning and associated wasted space is also reduced sixteen-fold. Objects referenced from ambiguous roots are pinned on the line(s) they occupy, but Immix may copy all other objects according to its usual heuristics. This feature limits the impact of ambiguous roots to internal line fragmentation. Immix allocates into both completely empty blocks and partially occupied blocks, but never into used lines. When allocating into an empty block, the corresponding object map entries are first zeroed and then set as each object is allocated.

мне кажется, что для БД GC реально не особо нужен, особено, если важно latency, но есть куча других приложений, где без GC сложно. К упоминавшимся уже lock-free можно добавить функциональное программирование

а вот в фп получить циклические зависимости по моему нереально и для них можно сильно все проще сделать

в принципе, разные концепции отсюда итак есть в современных аллокаторах, но тут они похоже все вместе подогнаны именно под gc

Получается что если к подсчету ссылок добавить разруливание циклических ссылок то как раз и получится GC нового поколения (время которого не будет зависеть от количества объектов в отличие от всех существующих gc). Интересно кто-то уже это придумал?

но фпшников этому не научишь, потому что они не захотят сколько бы то ни было ручное управление памятью

Плюс там не сказано, что все эти регионы и кэш линии могут переиспользоваться и все это еще и cache-friendly и там практически нет фрагментации

в jemalloc, кстати, применяется интересная концепция для этого: они все extent'ы (хранилище больших объектов) и slab'ы (малых объектов) кладут в PairingHeap по виртуальному адресу. Тем самым слабы и экстенты с меньшим виртуальным адресом будут использованы с большей вероятностью и со временем там должны накопиться горячие объекты, а холодные, напротив, будут дальше от начала бина

Удивительно, значит в AssemblyScript GC нового поколения) Так как используется ARC для всего кроме циклически связанных объектов