Comments 25
Интересная реализация. Но мне кажется, что полноценный сборщик мусора необходимо реализовывать в самом компиляторе (чего и побаиваюсь в C++). Который бы автоматически следил за выделяемой памятью (упорядочивая и освобождая при необходимости) и учитывал модель памяти. Иначе это будет всё тот же менеджер памяти.
писать статьи дико тяжело — такие развёрнутые, да…
писать статьи дико тяжело — такие развёрнутые, да…
Поддерживаю насчёт реализации GC в самом языке.
Мне кажется в С++ сборщик мусора не сильно необходим (может только для того, что бы не отставать от остальных языков).
Если разработчик задумывается о GC — возможно ему просто нужно использовать специализированные аллокаторы. Они, конечно, не дадут вам полностью забыть о проблемах памяти, но позволят более эффективно ей пользоваться.
Для С++ разработчики игр эту область очень сильно «проработали».
Мне кажется в С++ сборщик мусора не сильно необходим (может только для того, что бы не отставать от остальных языков).
Если разработчик задумывается о GC — возможно ему просто нужно использовать специализированные аллокаторы. Они, конечно, не дадут вам полностью забыть о проблемах памяти, но позволят более эффективно ей пользоваться.
Для С++ разработчики игр эту область очень сильно «проработали».
Написать что-то полноценное у меня даже намерения не было. Я просто хотел показать, что в самой технологии ничего сверхъестественного нет. Т.е. да, в Java работает какой-то продвинутый оптимизированный алгоритм, но единственное реальное отличие между ним и моей сотней строк — это то, что компилятор сам может вставлять что надо и куда надо, а в плюсах что-то придется делать то же самое вручную.
Интересно было бы рассмотреть подход memcached при создании сборщика мусора. То есть разделение памяти на слабы определённого размера. Каждый объект англизируется по размеру и пишется к объектам похожего размера.
При таком подходе:
* Никогда не нужно заниматься дефрагментацией, все операции по: записи, инвалидации, поиску — O(1)
* А из минусов: память используется неэффективно (есть много мелких пропусков) (хотя настройками и автолевелингом слабов это можно свести к минимуму)
При таком подходе:
* Никогда не нужно заниматься дефрагментацией, все операции по: записи, инвалидации, поиску — O(1)
* А из минусов: память используется неэффективно (есть много мелких пропусков) (хотя настройками и автолевелингом слабов это можно свести к минимуму)
Спасибо большое! То, что мне надо — сейчас пытаюсь слепить форт-машину, но с автоматическим менеджером памяти. Наверное, прикручу что-то такое.
Упражнение хорошее, но в реальности такой подход сложно применить.
Беда в том, что работа с такими объектами сильно ограничена:
— внутри такого объекта нельзя использовать переменные-члены произвольного типа, а только те, что поддерживают сборщик
— нельзя сохранять указатели и ссылки на объекты, контроллируемые сборщиком, и переменные-члены таких объетов
В общем, эта такая вещь в себе, которую ни с чем не сынтегрируешь.
А вообще в С++ просто предполагается другой подход по управлению памятью. И нельзя рассматривать shared_ptr как некий сборщик мусора. Он не для этого предназначен просто. Очень плохая тенденция в последнее время, кстати, возникла — пихать везде shared_ptr, не думая.
По быстрому созданию большого количества маленьких объектов, есть, кстати, глава у Александреску в Modern C++ Design:. Small-Object Allocation
Беда в том, что работа с такими объектами сильно ограничена:
— внутри такого объекта нельзя использовать переменные-члены произвольного типа, а только те, что поддерживают сборщик
— нельзя сохранять указатели и ссылки на объекты, контроллируемые сборщиком, и переменные-члены таких объетов
В общем, эта такая вещь в себе, которую ни с чем не сынтегрируешь.
А вообще в С++ просто предполагается другой подход по управлению памятью. И нельзя рассматривать shared_ptr как некий сборщик мусора. Он не для этого предназначен просто. Очень плохая тенденция в последнее время, кстати, возникла — пихать везде shared_ptr, не думая.
По быстрому созданию большого количества маленьких объектов, есть, кстати, глава у Александреску в Modern C++ Design:. Small-Object Allocation
Как раз недавно читал про реализацию GC в .NET. Там во время сборки мусора куча «утрамбовывается», то есть данные переносятся в пределах одного и того же блока с возможным перекрытием. У вас, если я правильно понял, «куча» копируется целиком, то есть во время сборки требуемый объем памяти равен двум размерам кучи?
Из-за этого создание новых объектов начинает занимать целую вечность и нативный код начинает завидовать Питону.
Насколько помню, в CPython сборщик мусора ничего не перемещает, так что он тоже восприимчив к фрагментации.
“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/
Не вижу смысла для С/C++ в построении GC. Сборка мусора имеет смысл для языков с другой идеологией, а для С/C++ фактор скорости является одним из главных. При этом нахожу странным написанием не только этого варианта, но других GC для C++ людей очевидно не сталкивающихся с проблемой постоянного выделения и возврата памяти, которое приводит к сильной фрагментации кучи. Я постоянно сталкиваюсь с такими задачами и знаю, что говорю.
Как говорится, времена в студию, Сэр!
Как говорится, времена в студию, Сэр!
Еще стоит глянуть в сторону ARC, который сейчас продвигают в Objective-C.
Любопытствующим можно посоветовать дополнительно ознакомиться с книгой
Шилдт Г. «Искусство программирования на C++» — СПб.: БХВ-Петербург, 2005
глава 2. Простой сборщик мусора на C++.
Шилдт Г. «Искусство программирования на C++» — СПб.: БХВ-Петербург, 2005
глава 2. Простой сборщик мусора на C++.
Нарушение выравнивания на современных процессорах сильно замедляет работу программы, а старые ARM вообще отказываются в таких условиях работать
Современные процессоры уже абсолютно толерантны (особенно при использовании правильных инструкций) к выравниванию. А во времена C2D проигрыш был в районе 5% (прямо на хабре пост был).
UFO just landed and posted this here
Мне кажется там логическая ошибка (на Stackoverflow вместе с Александреску). Дело в том что GC тоже не может знать когда обьект можно безопасно удалять если используются обычные указатели. В частности в той статье у Александреску его код очевидно с грохотом упадет независимо от того освобождается память через delete() или GC. Там требуются более кардинальные подходы, например отменить указатели вообще или заменить их все на shared_ptr, но тогда это уже не C++ а совершенно другой язык.
Нет, Boost Foundation с вами не свяжется, и по моему это к лучшему. Смотрите сами: с многопоточностью вообще никак не совместимо, деструкторы не вызываются и еще много чего в этом роде.
На самом деле то что у Вас получилось — это не очень ловкая попытка имплементировать std::shared_ptr не используя шаблонов, модели использования будут аналогичны.
На самом деле то что у Вас получилось — это не очень ловкая попытка имплементировать std::shared_ptr не используя шаблонов, модели использования будут аналогичны.
У refcount, конечно, есть свои преимущества, но The Boehm-Demers-Weiser conservative C/C++ Garbage Collector мне нравится значительно больше.
А еще лучше реализовать это как в Rust.
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Сборщик мусора на С++