Сборщик мусора на С++

[@blackmaster]

Интересная реализация. Но мне кажется, что полноценный сборщик мусора необходимо реализовывать в самом компиляторе (чего и побаиваюсь в C++). Который бы автоматически следил за выделяемой памятью (упорядочивая и освобождая при необходимости) и учитывал модель памяти. Иначе это будет всё тот же менеджер памяти.

писать статьи дико тяжело — такие развёрнутые, да…

[@lexxmark]

Поддерживаю насчёт реализации GC в самом языке.
Мне кажется в С++ сборщик мусора не сильно необходим (может только для того, что бы не отставать от остальных языков).
Если разработчик задумывается о GC — возможно ему просто нужно использовать специализированные аллокаторы. Они, конечно, не дадут вам полностью забыть о проблемах памяти, но позволят более эффективно ей пользоваться.
Для С++ разработчики игр эту область очень сильно «проработали».

[@Salabar]

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

[@gnomeby]

Интересно было бы рассмотреть подход memcached при создании сборщика мусора. То есть разделение памяти на слабы определённого размера. Каждый объект англизируется по размеру и пишется к объектам похожего размера.

При таком подходе:
* Никогда не нужно заниматься дефрагментацией, все операции по: записи, инвалидации, поиску — O(1)
* А из минусов: память используется неэффективно (есть много мелких пропусков) (хотя настройками и автолевелингом слабов это можно свести к минимуму)

[@valplo]

Спасибо большое! То, что мне надо — сейчас пытаюсь слепить форт-машину, но с автоматическим менеджером памяти. Наверное, прикручу что-то такое.

[@Lol4t0]

Упражнение хорошее, но в реальности такой подход сложно применить.

Беда в том, что работа с такими объектами сильно ограничена:
— внутри такого объекта нельзя использовать переменные-члены произвольного типа, а только те, что поддерживают сборщик
— нельзя сохранять указатели и ссылки на объекты, контроллируемые сборщиком, и переменные-члены таких объетов

В общем, эта такая вещь в себе, которую ни с чем не сынтегрируешь.

А вообще в С++ просто предполагается другой подход по управлению памятью. И нельзя рассматривать shared_ptr как некий сборщик мусора. Он не для этого предназначен просто. Очень плохая тенденция в последнее время, кстати, возникла — пихать везде shared_ptr, не думая.

По быстрому созданию большого количества маленьких объектов, есть, кстати, глава у Александреску в Modern C++ Design:. Small-Object Allocation

[@impwx]

Как раз недавно читал про реализацию GC в .NET. Там во время сборки мусора куча «утрамбовывается», то есть данные переносятся в пределах одного и того же блока с возможным перекрытием. У вас, если я правильно понял, «куча» копируется целиком, то есть во время сборки требуемый объем памяти равен двум размерам кучи?

[@Salabar]

Ну да. Это более старый подход. Он же еще и в первых JVM, кажется, применялся.

[@mraleph]

Оба подхода гораздо старее JVM и были для LISP разработаны.

«утрамбовка» это чаще LISP2 опубликованный в 67м, а простое копирование — это Cheney, опубликованный в 70м, т.е. позже. Cheney — это частый выбор для сборки мусора в молодом поколении.

[@WGH]

Из-за этого создание новых объектов начинает занимать целую вечность и нативный код начинает завидовать Питону.

Насколько помню, в CPython сборщик мусора ничего не перемещает, так что он тоже восприимчив к фрагментации.

[@Amarantine]

“But I think that Garbage Collection is not as critical for C++ as it is for many of the other languages. We just don’t generate that much garbage” Bjarne Stroustrup. Взято отсюда: habrahabr.ru/post/139064/

[@bya]

Не вижу смысла для С/C++ в построении GC. Сборка мусора имеет смысл для языков с другой идеологией, а для С/C++ фактор скорости является одним из главных. При этом нахожу странным написанием не только этого варианта, но других GC для C++ людей очевидно не сталкивающихся с проблемой постоянного выделения и возврата памяти, которое приводит к сильной фрагментации кучи. Я постоянно сталкиваюсь с такими задачами и знаю, что говорю.

Как говорится, времена в студию, Сэр!

[@KilgortTraut]

Еще стоит глянуть в сторону ARC, который сейчас продвигают в Objective-C.

[@impersonalis]

Любопытствующим можно посоветовать дополнительно ознакомиться с книгой
Шилдт Г. «Искусство программирования на C++» — СПб.: БХВ-Петербург, 2005
глава 2. Простой сборщик мусора на C++.

[@dimoclus]

Нарушение выравнивания на современных процессорах сильно замедляет работу программы, а старые ARM вообще отказываются в таких условиях работать

Современные процессоры уже абсолютно толерантны (особенно при использовании правильных инструкций) к выравниванию. А во времена C2D проигрыш был в районе 5% (прямо на хабре пост был).

[@degs]

Мне кажется там логическая ошибка (на Stackoverflow вместе с Александреску). Дело в том что GC тоже не может знать когда обьект можно безопасно удалять если используются обычные указатели. В частности в той статье у Александреску его код очевидно с грохотом упадет независимо от того освобождается память через delete() или GC. Там требуются более кардинальные подходы, например отменить указатели вообще или заменить их все на shared_ptr, но тогда это уже не C++ а совершенно другой язык.

[@degs]

Нет, Boost Foundation с вами не свяжется, и по моему это к лучшему. Смотрите сами: с многопоточностью вообще никак не совместимо, деструкторы не вызываются и еще много чего в этом роде.
На самом деле то что у Вас получилось — это не очень ловкая попытка имплементировать std::shared_ptr не используя шаблонов, модели использования будут аналогичны.

[@Salabar]

Про Boost Foundation — предполагалось как вычурный синоним «никогда», но, видимо, из контекста не видно. :)

[@donnerjack13589]

У refcount, конечно, есть свои преимущества, но The Boehm-Demers-Weiser conservative C/C++ Garbage Collector мне нравится значительно больше.

[@donnerjack13589]

А еще лучше реализовать это как в Rust.

[@bak]

Может быть в том, что проще этого не делать? :)