Почему в C++ нет сборщика мусора?

Это один из десяти самых распространенных мифов о C++, которые постоянно распространяются ненавистниками. Сборка мусора не «встроена», но есть несколько простых способов сделать это C++. Публикация комментария, потому что другие уже ответили лучше, чем я мог бы ниже :)

Но в этом вся суть в том, что он не является встроенным, это нужно делать самому. Реальность по размеру: встроенная, библиотечная, самодельная. Я сам использую C++ и определенно не ненавижу его, потому что это лучший язык в мире. Но управление динамической памятью - это боль.

@Davr - Я не ненавистник C++ и даже не пытаюсь утверждать, что C++ нужен сборщик мусора. Я спрашиваю, потому что знаю, что Бьярн Страуструп сказал, что он БУДЕТ добавлен, и мне было просто любопытно, каковы были причины его невыполнения.

См. Также stackoverflow.com/questions/819425/….

я думаю, что лучший вопрос; почему стратегия сборки мусора не является обязательной в C++? и почему исходное предложение C++ 0x не допускало частичного gc в программе?

В этой статье Сборщик Boehm для C и C++ от доктора Доббса описывается сборщик мусора с открытым исходным кодом, который можно использовать как с C, так и с C++. В нем обсуждаются некоторые проблемы, возникающие при использовании сборщика мусора с деструкторами C++, а также со стандартной библиотекой C.

С ++ 11, по-видимому, допускает это, «если реализация выберет это»: stackoverflow.com/questions/15157591/…

@rogerdpack: Но на данный момент это не так полезно (см. мой ответ ...), поэтому маловероятно, что реализации будут инвестировать в его наличие.

Я определенно понимаю вашу точку зрения, но чувствую себя обязанным спросить: разве Java не используется примерно в таком же количестве приложений?

Нет. Java не подходит для высокопроизводительных приложений по той простой причине, что у нее нет таких же гарантий производительности, как у C++. Таким образом, вы найдете его в сотовом телефоне, но не в коммутаторе сотовой связи или суперкомпьютере.

Вы всегда можете купить больше сервера, но не всегда можете купить больше процессора для сотового телефона, уже находящегося в кармане клиента!

Java значительно повысила производительность ЦП. По-настоящему неразрешимая проблема - это использование памяти, Java по своей природе менее эффективна с точки зрения памяти, чем C++. И эта неэффективность связана с тем, что это сборщик мусора. Сборка мусора не может быть одновременно быстрой и эффективной с точки зрения памяти - факт, который становится очевидным, если вы посмотрите, насколько быстро работают алгоритмы сборки мусора.

@Zathrus java может выиграть по пропускной способности b / c оптимизирующего jit, но не по задержке (в реальном времени) и, конечно, не по объему памяти.

@Zathrus - Java на мэйнфрейме: www-03.ibm.com/systems/z/os/zos/tools/java. Контроллер коммутатора Java - floodlight.openflowhub.org. Гарантии производительности в реальном времени важны только для относительно небольшого подмножества высокопроизводительных приложений, в большинстве областей HPC Java была сильна в течение долгого времени.

@Zathrus Разве 864 ядра не подходит для суперкомпьютера? Разве 6 миллионов заказов в секунду в одном потоке в торговле в реальном времени не считается высокопроизводительным? У Java по-прежнему есть недостатки, но она хороша почти для всех задач.

Я бы становиться ненавидел, если бы C++ принудил меня к сборке мусора! Почему люди не могут использовать smart_ptr's? Как бы вы сделали разветвление в стиле Unix на низком уровне, с мешающим сборщиком мусора? Это повлияет на другие вещи, такие как потоки. Python имеет свой глобальная блокировка интерпретатора в основном из-за его сборки мусора (см. Cython). Держите его подальше от C / C++, спасибо.

Как сделать прозрачную сборку мусора непрозрачных структур API операционной системы void *?

@ unixman83: Основная проблема со сборкой мусора с подсчетом ссылок (например, std::shared_ptr) - это циклические ссылки, которые вызывают утечку памяти. Поэтому вы должны осторожно использовать std::weak_ptr, чтобы разорвать циклы, а это беспорядочно. У GC стиля метки и развертки этой проблемы нет. Между потоками / разветвлением и сборкой мусора нет внутренней несовместимости. И Java, и C# обладают высокопроизводительной вытесняющей многопоточностью и сборщиком мусора. Есть проблемы, связанные с приложениями реального времени и сборщиком мусора, поскольку большинство сборщиков мусора должны останавливать запуск мира.

«Основная проблема со сборкой мусора с подсчетом ссылок (например, std::shared_ptr) - это циклические ссылки» и ужасная производительность, что иронично, потому что более высокая производительность обычно является оправданием для использования C++ ... flyingfrogblog.blogspot.co.uk/2011/01/…

"Как бы вы сделали разветвление в стиле Unix на низком уровне". Точно так же языки с GC, такие как OCaml, делают это в течение ~ 20 лет или больше.

«Python имеет глобальную блокировку интерпретатора в основном из-за сборки мусора». Аргумент Строумана. У Java и .NET есть GC, но ни у одной из них нет глобальных блокировок.

Проблема, с которой я сталкиваюсь с принудительным и широко распространенным использованием GC, заключается в том, что трудно избежать утечек. Если мы полностью перейдем к наиболее ручным формам управления памятью, таким как C, единственный способ утечки памяти - это не иметь free, соответствующего malloc/calloc. В GC автор чего-то вроде объекта текстуры мог бы сделать все идеально, чтобы выделить текстуру и удалить все существующие ссылки, которые он создал на нее во время ее удаления - абсолютно идеально, проверено модулем. И все же могут быть сотни мест, где утечка текстуры - все, что требуется в GC, чтобы ресурс текстуры ...

... имеет кучу логических утечек, связанных с тем, что он не освобождается до завершения работы программы, чтобы любой случайный разработчик просто сохранил ссылку на текстуру в некотором агрегате и не смог удалить ссылку в надлежащее время. Что еще хуже, такие частые логические утечки, связанные с GC, в очень сложных кодовых базах и в больших командах гораздо труднее обнаружить, отладить и исправить, чем отсутствие соответствия free и malloc. Они не отображаются, например, в valgrind, поскольку представляют собой логические утечки, а не физические.

Для меня это гораздо более серьезная проблема, чем часто упоминаемые проблемы, связанные с производительностью. Это связано с правильностью - и для получения некорректного кода, который просачивается без GC, требуется только халатность со стороны человека, выделяющего память, и часто намного легче обнаружить / исправить даже в этих наихудших сценариях. С GC требуется только халатность со стороны всех участников (даже стороннего плагина) для утечки некоторых из самых больших ресурсов в системе, и эти типы утечек труднее всего обнаружить / исправить (иногда соперничающие с условиями гонки старания в отладке).

Ссылка "источник" мертва. Пожалуйста, обновите ответ. Я пробовал, но кнопка редактирования не работает.

@DrunkCoder После любой вовлеченный случайный разработчик просто сохранил ссылку на текстуру в некотором агрегате и не смог удалить ссылку в надлежащее время вы старательно вызываете free, а затем другой случайный разработчик использует эту ссылку, и вам всем нравится отлаживать неопределенное поведение, убивая ваших кошек и сжигая ваши дома. Хотя valgrind находит ссылку и код доступа, я не понимаю, насколько это проще, чем анализировать утечку памяти, которую можно получить с помощью GC.

С практической точки зрения, если бы такое неопределенное поведение могло легко пролететь незамеченным, и программа могла бы работать нормально или в некоторой степени, я бы согласился. Но в большинстве случаев такой UB имеет тенденцию проявляться в виде сбоя, повреждения кучи, segfault и т. д., И все это может быть немедленно обнаружено во время отладки. Если вы работаете над критически важным программным обеспечением, утечка которого - не конец света, я согласен с тем, что сборщик мусора - очень разумный выбор. Но в остальном я больше всего стремлюсь к тому, чтобы ошибки были как можно проще воспроизводить последовательно и как можно проще выявлять.

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

По моему личному опыту, ошибки, которые легко воспроизводятся последовательно, как, например, ошибки сегментации, как правило, сообщаются и исправляются, если они не были обнаружены в нашем модульном / интеграционном тестировании до того, как продукт официально отправится. Между тем ошибки, которые чрезвычайно сложно воспроизвести / обнаружить, могут оставаться в продукте годами - среди тех, с которыми я столкнулся, были условия гонки, неинициализированные переменные и утечки сборщика мусора. Только подумайте, как написать тест, который может обнаружить такую ​​утечку сборщика мусора с корневым ресурсом? Не думаю, что это возможно, но можно сразу обнаружить доступ к зависшим указателям.

@maaartinus Наконец, valgrind не может обнаружить логическую утечку AFAIK. Корневой ресурс не обязательно продолжает использовать память после завершения работы. Он просто продолжает занимать память во время работы приложения. Как только приложение начинает закрываться, объект (скажем, шейдер), который хранит текстуру, удаляется из системы, и текстура, на которую он ссылается, также освобождается. Поскольку сборщик мусора полагается на неявное уничтожение, а не явное, невозможно сказать, какой ресурс должен быть освобожден, когда именно. Текстура просто не была освобождена достаточно рано, когда пользователь запросил ее.

Тип утечки, о котором я говорю, - это тот, где, скажем, эти шейдеры хранят ссылки на текстуры, которые они используют. То же самое и с библиотекой изображений. Однако пользователь может явно запросить удаление текстуры из библиотеки изображений, после чего шейдеры должны освободить свои ссылки на текстуру, чтобы сборщик мусора мог собрать свою память. Однако они не удаляют / не обнуляют эти ссылки, поэтому текстуры молча продолжают занимать память, пока не будут удалены сами шейдеры. Это тот вид утечки GC, который, по моему опыту, незаметен и никогда не обнаруживается тестированием / valgrind.

А пока возьмем аналог с явным уничтожением. В том случае, когда пользователь запрашивает удаление текстуры из библиотеки изображений, разработчик явно просит ее уничтожить. Теперь, если у нас есть та же ошибка, описанная выше, когда шейдеры не выпускают свои указатели / ссылки на текстуру, они могут затем попытаться получить к ней доступ, что приведет к висящему указателю UB (обычно это приводит к ужасному сбою). Но это, как правило, немедленно обнаруживается и воспроизводится QA, если не нашими автоматическими тестами - так что я на самом деле считаю это гораздо более предпочтительным.

Тем не менее, как повторяющееся предостережение, я не работаю в критически важных областях, где желательно, чтобы приложение продолжало изящно работать при наличии ошибок (там я, вероятно, действительно хотел бы GC). Я работаю в компании, которая предпочла бы обнаруживать и воспроизводить такие ошибки как можно быстрее и проще, а в идеале еще до того, как продукт будет выпущен, даже если ошибка приводит к серьезному сбою. Так что сборщик мусора стал для меня занозой, по крайней мере, для очень больших кодовых баз с большими командами - они приводят к некоторым из самых трудных для обнаружения ошибок утечек, которые я обнаружил.

И фух, извиняюсь за длинные комментарии, но я думаю, что для многих приложений небольшая утечка во время выполнения, вероятно, не представляет большого труда. Но есть некоторые области, такие как игры или, в моем случае, VFX, где нетривиальные ресурсы выделяются довольно часто - с VFX художник может загрузить HDR-текстуру высокого разрешения, которая занимает гигабайт. Так что неспособность освободить его в надлежащее время - это действительно неприятная ошибка в нашем случае, а не что-то относительно безобидное, и мы не хотим, чтобы такие ошибки легко оставались незамеченными, поскольку GC может позволить.

И последнее, (последнее, я обещаю!) - давайте рассмотрим сценарий, который не разрешен сборщиком мусора - сценарий, в котором исходный разработчик вообще не освобождает текстуру - никакая часть системы не освобождает текстуры. Это тот вид физической утечки, который valgrind легко обнаруживает, поэтому его также очень легко обнаружить ... Это только логическая утечка в стиле GC в этом сценарии, которую я нашел невероятно трудной для обнаружения в больших базах кода (миллионы LOC), потому что вы видите тот факт, что приложение загружает все больше и больше памяти, чем дольше оно работает, но кто это сделал? Кому не удалось обнулить / удалить реф?

... и в моем случае некоторые длительные исследования фактически привели меня к выводу, что даже не наш код вызывает эти утечки сборщика мусора. Это были плагины сторонних производителей, которые загружали пользователи ... и все плагины, которые должны были сделать, чтобы массивные текстуры или сетки просачивались в систему, просто сохраняли ссылку на них и не могли установить для них нулевое значение в соответствующее время ... и это очень пугающая перспектива, когда что-либо, написанное кем-либо из миллионов LOC, может стать владельцем общего ресурса, просто сохранив ссылку на него в приложении, где не следует игнорировать логические утечки.

@DrunkCoder Valgrind действительно не может найти логические утечки, и нет возможности их протестировать, но есть другие инструменты для языков, собранных с помощью GC. Вы говорите с точки зрения C++, которая полностью отличается от Java. Действительно, сборщик мусора не помогает напрямую с логическими утечками, но делает их маловероятными. Какой у вас шейдер для ссылки? В Java это, вероятно, будет легкий объект, выделяемый при необходимости, и он сам получит сборку мусора. Это может быть синглтон, вместо того, чтобы содержать ссылку на текстуру ток, а затем он будет пропускать ее только до тех пор, пока не будет заменен новой.

@maaartinus Это проблема управления ресурсами, не решаемая ни одной языковой функцией AFAIK (хотя в Java могут быть хорошие инструменты отладки, о которых я не знаю, чтобы помочь обнаружить эти утечки). Скажем, у вас есть центральный граф сцены в программном обеспечении. Графики сцены хранят такие вещи, как шейдеры, сетки, текстуры, камеры и т. д., И некоторые из этих вещей реализованы сторонними организациями (сторонние шейдеры, загружаемые плагинами). Типы утечек, с которыми я столкнулся, были теми, где у вас может быть что-то вроде сетки или текстуры, на которую ссылается (и, следовательно, принадлежит) ...

... много разных вещей - камеры могут хранить список мешей, которые нужно исключить из рендеринга. Некоторые шейдеры могут ссылаться на определенные сетки и текстуры. Средство рендеринга может хранить ссылки на всевозможные объекты сцены, которые он хочет визуализировать ... именно тот факт, что все эти вещи фактически разделяют владение этими ресурсами, стал для меня такой головной болью. Логично, что владелец был только один - граф сцены владеет сетками, а библиотека изображений - текстурами. Если бы наша команда и сторонние разработчики плагинов знали о фантомных и слабых ссылках и использовали их ...

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

В нашем случае шейдеры были легкими объектами - очень легкими - в основном это был код. Но они могут ссылаться на что-то не легкое, например, сетку с миллионом полигонов или HDR-текстуру 8000x8000 пикселей. И когда пользователь запрашивает удалить такую ​​текстуру из библиотеки изображений, шейдер (который может быть шейдером плагина стороннего производителя) может не обработать это событие и должным образом освободить текстуру ... и тогда начинаются мои кошмары.

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

... но были случаи, когда для кратковременного потока имело смысл продлевать время жизни ресурса до тех пор, пока он не завершил обработку. Там я нахожу GC чрезвычайно полезным, но большую часть времени я нахожу его слишком пугающим и слишком подверженным ошибкам, когда он используется для хранения постоянных ссылок в более чем одном постоянном месте.

@DrunkCoder Похоже, вы работаете с Java. На Java существует масса критически важных приложений и очень мало жалоб на утечку памяти. Существуют утечки загрузчика классов, это отдельная проблема, так что давайте о них забудем. Многие проблемы действительно решаются с помощью слабых ссылок, особенно таких как «список мешей, которые нужно исключить из рендеринга». Если ваши шейдеры настолько легкие, вы можете выделить их и забыть после того, как они выполнили свою работу, чтобы они получили GD. Если это невозможно, и плагин не может быть изменен, то вы можете не давать ему реальную вещь ...

Это правда, и я видел свою долю очень грамотно разработанных приложений на языках GC - я не хочу, чтобы это звучало так, будто это автоматически приведет к утечке программного обеспечения. Но я действительно считаю GC чем-то вроде лезвия бритвы или бензопилы в этом отношении, если утечки не являются доброкачественными, учитывая, насколько легко одна, даже третья сторона, пишущая плагин, может вызвать утечку программного обеспечения огромного ресурса, просто сохранив ссылку на него. и не отпускать его в ответ на соответствующее событие. Хотелось бы найти золотую середину, потому что я тоже не люблю ручное управление памятью, но все же предпочитаю его.

Позвольте нам продолжить обсуждение в чате.

Что мне не нравится в STL ATM, так это неудобный способ использования итераторов для работы с отсутствующим сборщиком мусора. В Linq я мог бы просто выполнить .Select (), в C++ отфильтрованные элементы перемещаются в начало, а итератор перемещается к первому выбранному элементу. Думаю, чтобы вы могли освободить предыдущие предметы. Иначе утечка памяти. Все это могло бы быть намного лучше с GC. На данный момент они просто неудобные. ИМХО

Я не думаю, что GC требует виртуальную машину. Компилятор может добавлять код ко всем операциям с указателями для обновления глобального состояния, в то время как отдельный поток запускается в фоновом режиме, удаляя объекты по мере необходимости.

Я согласен. Вам не нужна виртуальная машина, но как только вы начинаете управлять своей памятью, как это происходит в фоновом режиме, я чувствую, что вы оставили фактические «электрические провода» и имеете своего рода ситуацию с виртуальной машиной.

«с производительностью, которая выгодно отличается от других языков со сборкой мусора». Цитата?

Моя ссылка не работает. Я написал этот ответ 5 лет назад.

Хорошо, я надеялся на независимую проверку этих утверждений, то есть не со стороны Страуструпа или Бема. :-)

Сборщик мусора и деструкторы - это решенная проблема, хороший шаг в сторону от Бьярна. Деструкторы не запускаются во время сборки мусора, потому что сборщик мусора не в этом. GC в C++ существует, чтобы создать понятие бесконечного объем памяти, а не бесконечного количества других ресурсов.

Если деструкторы не запускаются, это полностью меняет семантику языка. Я предполагаю, что, по крайней мере, вам понадобится новое ключевое слово "gcnew" или что-то в этом роде, чтобы вы явно разрешили сборку мусора для этого объекта (и, следовательно, вы не должны использовать его для обертывания ресурсов, помимо памяти).

Это подделка. Поскольку C++ имеет явное управление памятью, вам нужно выяснить, когда нужно освободить каждый объект. С GC все не хуже; скорее, проблема сводится к выяснению того, когда освобождены определенные объекты, а именно те объекты, которые требуют особого внимания при удалении. Опыт программирования на Java и C# показывает, что подавляющее большинство объектов не требует особого внимания и может быть безопасно оставлено на усмотрение сборщика мусора. Оказывается, одна из основных функций деструкторов в C++ - освобождать дочерние объекты, которые GC обрабатывает за вас автоматически.

@ NateC-K: Одна вещь, которая улучшена в GC по сравнению с не-GC (возможно, самая большая вещь) - это способность надежной системы GC гарантировать, что каждая ссылка будет продолжать указывать на один и тот же объект, пока существует ссылка. Вызов Dispose для объекта может сделать его непригодным, но ссылки, которые указывали на объект, когда он был жив, продолжат действовать после его смерти. Напротив, в системах без GC объекты могут быть удалены, пока существуют ссылки, и редко существует какой-либо предел хаосу, который может быть нанесен, если одна из этих ссылок используется.

Хотел бы я принять два ответа! Это просто здорово. Следует отметить, что в отношении производительности сборщик мусора, работающий в отдельном потоке, на самом деле довольно распространен (он используется в Java и .Net). Конечно, это может быть неприемлемо для встроенных систем.

Всего два типа? Как насчет копирования коллекционеров? Коллекционеры поколений? Различные параллельные сборщики (включая беговую дорожку Бейкера в режиме жесткого реального времени)? Различные коллекционеры гибридов? Черт, полное невежество в индустрии этой области иногда меня удивляет.

Я сказал, что их всего 2 типа? Я сказал, что было 2, которые были широко развернуты. Насколько мне известно, Python, Java и C# теперь используют алгоритмы Mark и Sweep (раньше в Java был алгоритм подсчета ссылок). Чтобы быть еще более точным, мне кажется, что C# использует GC Generational для второстепенных циклов, Mark And Sweep для больших циклов и Copying для борьбы с фрагментацией памяти; хотя я бы сказал, что сердце алгоритма - это Mark And Sweep. Знаете ли вы какой-нибудь основной язык, использующий другую технологию? Я всегда рада учиться.

Вы только что назвали один основной язык, который использует три.

@ ТОЛЬКО МОЕ ПРАВИЛЬНОЕ МНЕНИЕ, Твое высокомерие регулярно меня удивляет. Но высокомерные люди иногда бывают крутыми ...;)

Существуют также инкрементные и поколенные сборщики мусора. Сборщики мусора могут влиять на RAII, поэтому, если мы хотим иметь сборщик мусора для указателей, нам потребуется какой-то тип объекта местный, который действует как объект стека ... также очень много случаев, когда автоматическая сборка мусора просто не нужна.

@ JSPerfUnkn0wn: об этом уже говорилось ТОЛЬКО МОЕ правильное МНЕНИЕ. Я бы сказал, что сборщик мусора поколений основан на Mark & ​​Sweep (хотя они ограничивают алгоритм меньшим объемом). Что касается ненужности, проблема в том, что либо вы используете сборщик мусора и рискуете получить утечку пространства, либо используете ручную обработку и рискуете получить утечки памяти / устаревшие ссылки. Мне очень интересна система регионов Rust, и мне интересно, представит ли она альтернативу вышеуказанной проблеме.

Основное отличие состоит в том, что генерация и инкрементный сборщик мусора не должны останавливать работу мира, и вы можете заставить их работать в однопоточных системах без особых накладных расходов, время от времени выполняя итерации обхода дерева при доступе к указателям сборщика мусора (фактор можно определить по количеству новых узлов, а также по базовому прогнозу необходимости сбора). Вы можете пойти дальше GC, включив данные о том, где в коде произошло создание / модификация узла, что может позволить вам улучшить ваши прогнозы, и вы получите Escape Analysis бесплатно вместе с ним.

@ JSPerfUnkn0wn: честно говоря, что касается Mark & ​​Sweep, вы также можете избежать эффекта остановки мира, введя барьеры для чтения или записи и т. д., Так что на самом деле я рассматриваю генерацию как усовершенствование Mark & ​​Sweep. Очевидно, я лишь смутно затронул эту тему, во-первых, потому что это ТАКОЕ ответ, а во-вторых, потому что я определенно не эксперт в этой теме. Не могли бы вы добавить свой ответ?

@MatthieuM. вы сказали «Mark And Sweep быстрее (меньше влияет на общую производительность), но страдает синдромом« заморозить мир »», это все, что я тоже отвечал. Меня не волнует, назовете ли вы их может вариациями Mark & ​​Sweep или хотите называть их "Egg and Bacon", все, что меня волнует, - это реализация и четкое общение между программистами, а не то, что аргументирует это должен называться: ) ... теперь вернемся к теме, GC (или назовем его Automatic GC, как его называет Python) не должен останавливать мир, это все, на что я намекал (и другие вещи, которые я упомянул) :)

@MatthieuM. Что касается «Возможно, вы могли бы добавить свой собственный ответ», в этом нет необходимости, эти ответы хороши, как и ваш :) И, как вы сказали, эти алгоритмы являются усовершенствованием Mark & ​​Sweep, хотя я бы пошел дальше, чтобы указать, что они только когда-либо будут проходить через узлы (что выделяет их как варианты M&S). Что определяет их больше всего, так это то, как различается их поведение, например, я не просто отмечаю, у меня есть 5 состояний разделов / узлов, у Mark & ​​Sweep - 2, и я видел один в Википедии с 3. Я никогда не пытался создать Хотя и поколениями, но у меня есть несколько идей.

"страдает синдромом" замораживания мира ". Дейкстра решил эту проблему в 1975 году с помощью своей схемы трехцветной маркировки для инкрементальной зачистки меток. Такие языки, как OCaml (1996), используют это и, следовательно, не страдают от этой проблемы. cs.utexas.edu/~EWD/ewd05xx/EWD595.PDF

@JonHarrop: Я коснулся возможных улучшений после схемы «подсчета ссылок», однако параллельные сборщики мусора далеки от тривиальности и сами по себе требуют затрат; вам нужны либо барьеры чтения, либо барьеры записи в других потоках, о которых, я думаю, говорил Дейкстра, часть сотрудничество. Может стоит поставить наивный перед Mark and Sweep?

Обратите внимание, что я говорил об инкрементных сборщиках мусора, а не о параллельных сборщиках мусора. Инкрементальные сборщики мусора тривиальны. Реальные параллельные сборщики мусора, как правило, сложны, но простые параллельные сборщики мусора существуют (например, VCGC). Вы можете устранить неограниченные паузы GC, используя отдельные кучи с инкрементными GC (например, OCaml и Erlang) вместо глобального параллельного GC, но вам нужно глубоко копировать сообщения. Ваше утверждение, безусловно, верно в отношении наивной зачистки меток, но тогда никто не использует наивную метку. Производственные сборщики мусора, как правило, передаются поколению с копирующими коллекторами между молодыми поколениями и разметкой / сжатием для старого поколения.

@JonHarrop: Проблема, применительно к C и C++, заключается в том, что копирующие сборщики просто не работают: вы имеете право в C и C++ сохранять значение указателя в целое число и даже просто смещение по сравнению с вашим собственным адресом, поэтому GC не может отследить ссылки, чтобы обновить их при перемещении. Точно так же адреса могут использоваться как идентификаторы объектов, поэтому вы не можете копировать объект за спиной разработчика. И, конечно же, память легко распределяется между потоками. Это серьезно ограничивает возможные реализации GC.

@MatthieuM .: Чтобы пойти еще дальше: предположим, что программа неоднократно выделяла 1000 объектов с помощью new, заполняет их некоторыми данными, преобразует их адреса в числа, отображает их в течение 1/60 секунды, а затем оставляет объекты без выполнения delete. Позже программа позволяет пользователю ввести число, преобразовать его в адрес и использовать в предположении, что оно представляет собой допустимый объект. Если число, которое вводит пользователь, было отображено как адрес объекта, стандарт C++ требует, чтобы адрес оставался действительным.

@MatthieuM .: Хотя было бы довольно маловероятно, что пользователю удастся скопировать каждое отображаемое число [цифровая камера, безусловно, может захватывать произвольное заполнение экрана], а также любой объект, связанный с адресом, который исчез с экрана до того, как был записанный может быть безопасно удален, очевидно, что для программы было бы абсолютно невозможно узнать, какие адреса все еще существуют где-то вне компьютера, а какие нет.

Я понимаю, что вашему ответу уже 10 лет, но - я не думаю, что вы убедительно доказали, почему сборщик мусора необходим в сегодняшнем C++. Тот факт, что даже с RAII все еще возможны эффективные утечки памяти, не является таким случаем - потому что у вас могут быть утечки памяти и с GC - удерживая ссылки на выделенное пространство, которое вам не нужно и эффективно не будет использовать .

Я бы сказал, что даже если указать, что для правильной работы все объекты должны быть удалены, и только те объекты, которые были удалены, будут иметь право на сбор, компилятор служба поддержки для сборки мусора с отслеживанием ссылок может быть полезен, поскольку такой язык может гарантировать что использование удаленного указателя (ссылки) гарантированно перехватит, а не вызовет неопределенное поведение.

Даже в Java GC на самом деле не предназначен для выполнения чего-либо полезного AFAIK. Он мог бы назвать free для вас (я имею в виду free, аналогичный языку C). Но Java никогда не гарантирует вызова финализаторов или чего-то подобного. Фактически, C++ делает гораздо больше, чем Java, для выполнения операций записи в базу данных, очистки дескрипторов файлов и т. д. Java утверждает, что имеет "GC", но разработчики Java должны постоянно вызывать close(), и они должны быть очень осведомлены об управлении ресурсами, стараясь не вызывать close() слишком рано или слишком поздно. C++ избавляет нас от этого. ... (продолжение)

.. мой комментарий минуту назад не предназначен для критики Java. Я просто заметил, что термин «сборка мусора» - очень странный термин - он означает гораздо меньше, чем люди думают, и поэтому его трудно обсуждать, не понимая, что он означает.

@AaronMcDaid Это правда, что сборщик мусора вообще не помогает с ресурсами, не относящимися к памяти. К счастью, такие ресурсы выделяются довольно редко по сравнению с памятью. Более того, более 90% из них могут быть освобождены с помощью метода, который их назначил, поэтому try (Whatever w=...) {...} решает эту проблему (и вы получите предупреждение, когда забудете). Остальные тоже проблематичны с RAII. Вызов close() «все время» означает, что, возможно, один раз на десятки тысяч строк, так что это не так уж и плохо, в то время как память выделяется почти на каждой строке Java.

Сборку мусора следует использовать только для объектов, которые не получают ресурсы (т. Е. Просят другие объекты делать что-то от их имени «до дальнейшего уведомления»). Если Gadget не просит ничего делать от его имени, исходный код был бы совершенно безопасным в Java, если бы бессмысленный (для Java) оператор delete был удален.

@supercat, интересны объекты со скучными деструкторами. (Я не определил «скучный», но в основном деструкторы, которые никогда не нужно вызывать, за исключением освобождения памяти). Отдельный компилятор может обрабатывать shared_ptr<T> специально, когда T «скучный». Он может решить фактически не управлять счетчиком ссылок для этого типа, а вместо этого использовать GC. Это позволит использовать GC без необходимости уведомления разработчика. shared_ptr можно рассматривать просто как указатель GC для подходящего T. Но в этом есть ограничения, и это замедлит работу многих программ.

В хорошей системе типов должны быть разные типы для объектов кучи, управляемых сборщиком мусора и RAII, поскольку некоторые шаблоны использования очень хорошо работают с одним и очень плохо с другим. В .NET или Java оператор string1=string2; будет выполняться очень быстро независимо от длины строки (это буквально не что иное, как загрузка регистров и хранилище регистров) и не требует какой-либо блокировки, чтобы гарантировать, что если вышеуказанный оператор будет выполняться во время string2 записывается, string1 будет содержать либо старое значение, либо новое значение без неопределенного поведения).

В C++ присвоение shared_ptr<String> требует большой скрытой синхронизации, а назначение String может вести себя странно, если переменная читается и записывается одновременно. Случаи, когда кто-то хотел бы писать и читать String одновременно, не очень распространены, но могут возникнуть, например, если некоторый код хочет сделать текущие отчеты о состоянии доступными для других потоков. В .NET и Java такие вещи просто «работают».

Не могли бы вы прояснить кое-что, чтобы мы сравнивали подобное с подобным? В C++ вы имеете в виду неизменяемый класс String, как и класс String в Java? И поэтому вы никогда не назначаете String. Вы можете назначить String* или shared_ptr<String> (или String Java-справочник в Java). Меня смущает ваше обсуждение «присваивания» и «чтения и записи», потому что я предпочел бы ясность в том, что базовый объект неизменен.

В Java и .NET наиболее распространенным типом, используемым для инкапсуляции последовательности символов, является String, неизменяемый ссылочный тип, который используется, потому что это единственное, что может дать практическую семантику значения в Java, и единственное, что может дать семантику значения. в .NET без лишнего бокса [в .NET структура, инкапсулирующая char[], может быть лучше, чем объект кучи, за исключением проблемы бокса]. В целях сравнения я бы сказал, что его следует сравнивать с любым типом в C++, который наиболее эффективно представлял бы ...

... последовательность символов с семантикой значения. Для некоторых шаблонов использования лучше всего подойдет C++ String; для других shared_ptr<string> будет лучше. Однако есть некоторые шаблоны использования, для которых ни один тип C++ не может достичь эффективности и семантики строк GC, поскольку требуется единственная синхронизация с самим GC, и он обладает волшебными способностями для принудительной синхронизации с потоками, у которых нет других механизмов синхронизации. встроен в них.

Извините, что повторяюсь, но является ли ваш C++ String неизменным? Вы говорили ранее о чтении и письме, но писать не имеет смысла с неизменным String. что-то вроде using String = const std::vector<char>;. Я не могу думать о других проблемах, пока не выясню, что это за тип.

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

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

"Java не обещает когда-либо вызывать финализатор - возможно, он никогда не будет вызван" Интересный факт: ранние версии Java позволяли запускать финализатор, пока объекты все еще использовались; собственно говоря, еще был доработан ctor !!! Очевидно, это не вызвало много жалоб от толпы «C++ - отстой, потому что порядок f()+g() не детерминирован, а правила Java - потому что он детерминирован».

@curiousguy ничего не изменилось, если вы не примете правильных мер предосторожности, Java по-прежнему позволяет вызывать финализатор сразу после завершения конструктора. Вот пример из реальной жизни: «finalize () вызывал строго достижимые объекты в Java 8». Вывод - никогда не использовать эту функцию, что почти все согласны с исторической ошибкой дизайна языка. Когда мы следуем этому совету, язык дает нам любимый детерминизм.

Освобождение памяти и запуск деструкторов - слишком разные вопросы. (В Java нет деструкторов, это PITA.) GC освобождает память, но не запускает dtors.

Это действительно хороший момент, я недавно украл некоторые биты из своих указателей, потому что в противном случае было бы глупое количество промахов кеша.

@PasserBy: Интересно, сколько приложений, использующих 64-битные указатели, выиграют больше от использования масштабированных 32-битных указателей в качестве ссылок на объекты или хранения почти всего в 4 ГиБ адресного пространства и использования специальных объектов для хранения / извлечения данных с высоких -скорость хранения запредельная? У машин достаточно ОЗУ, поэтому потребление ОЗУ 64-битными указателями может не иметь значения, Кроме - что они потребляют вдвое больше кеша, чем 32-битные указатели.

Существует множество (более новых) алгоритмов, которые сложно реализовать без сборки мусора. Время шло. Инновации также связаны с новыми идеями, которые хорошо подходят для языков высокого уровня (сборка мусора). Попробуйте перенести любой из них на C++ без сборщика мусора, вы заметите неровности на дороге. (Я знаю, что должен привести примеры, но я как бы тороплюсь прямо сейчас. Извините. Одна, о которой я могу думать прямо сейчас, вращается вокруг постоянных структур данных, где подсчет ссылок не работает.).

Ну, он нужен (нужен GC), если вы перемалываете строки. Представьте, что у вас есть большие массивы строк (представьте, сотни мегабайт), которые вы строите по частям, затем обрабатываете и перестраиваете в разные длины, удаляя неиспользуемые, объединяя другие и т. д. знаю, потому что мне пришлось переключиться на языки высокого уровня, чтобы справиться. (Конечно, вы также можете создать свой собственный G C).

@ user1863152: В этом случае будет полезен специальный распределитель. Это по-прежнему не требует встроенного в язык сборщика мусора ...

кому: эйнпоклум: правда. Это просто лошадь для курсов. Моим требованием было обрабатывать динамически изменяющиеся галлоны информации о транспортных пассажирах. Увлекательная тема .. Действительно сводится к философии программного обеспечения.

GC, как обнаружили мир Java и .NET, наконец, имеет огромную проблему - он не масштабируется. Когда у вас есть миллиарды живых объектов в памяти, как в наши дни с любым нетривиальным программным обеспечением, вам придется начать писать код, чтобы скрыть вещи от GC. Наличие GC в Java и .NET - это бремя.

@ZachSaw: Какая часть программ когда-либо будет иметь в памяти хотя бы один миллиард живых объектов? Вы говорите, что все программы, в которых больше всего ничего нет, тривиальны?

@supercat: Может, он имел в виду миллионы объектов? Хотя и в этом случае это не так для «любого нетривиального» программного обеспечения.

@einpoklum: GC может нормально работать в масштабе «миллионы объектов». А для задач, которые хорошо подходят для модели, основанной на совместно используемых неизменяемых объектах, она, вероятно, лучше масштабируется для многоядерных систем, чем RAII, поскольку не требует взаимосвязанного счетчика ссылок.

@supercat: Я не утверждал, что сборщик мусора не работает - пожалуйста, не путайте мой ответ с комментарием Закса. Сказав это - он не обязательно масштабируется лучше, чем владение RAII-базой, потому что большая часть владения RAII не использует счетчики ссылок или блокировки. Кроме того, в C++ вы бы избегали использования большого количества std::shared_ptr - это звучит как обещание огромных потерь времени. Тем не менее, если ваше программное обеспечение работает именно так, то да, сборщик мусора может масштабироваться лучше, чем отдельные общие указатели.

@supercat под нетривиальным я имел в виду не связанные с памятью тривиальные, то есть приложения с большой памятью, такие как наша запатентованная высокопроизводительная система поиска документов, которая способна обрабатывать миллионы объектов, сортировать на лету и т.д. сам сайт StackOverflow. Разработчики написали множество технических блогов на эту тему.

@einpoklum: У разных задач разные требования. Я не думаю, что какой-то один подход может быть оптимальным для всех. RAII хорош для приложений, в которых все объекты имеют четкое право собственности; Сборщик мусора с трассировкой поколений хорош для приложений, где имеется большое количество объектов, которые оказываются равными, но не имеют других значимых взаимосвязей и имеют полезные сроки жизни, которые хорошо соответствуют ожиданиям поколений.

@supercat: Последний случай, хотя и важен, это не то, что просто произойдет в вашем приложении без вашего ведома; и, таким образом, должен быть достаточно хорошо обслуживаемым механизмом сборки мусора на основе библиотеки (если действительно невозможно избежать мусора).

@einpoklum: Системы, которые собираются использовать трассировку сборщиков мусора, должны интегрировать их в дизайн, поскольку такая интеграция позволит им делать то, что не сможет сделать основанный на библиотеке. Например, если foo содержит последнюю ссылку на объект, а поток 1 выполняет foo = bar; примерно в то же время, что другой выполняет boz = foo;, сборщик, интегрированный в Framework, сможет обрабатывать все связанные угловые случаи синхронизации потоков без какой-либо потребности в памяти. барьеры в коде любого потока. GC потребуется принудительно ввести некоторые дорогостоящие барьеры памяти ...

... когда он работает, но между циклами сборщика мусора не требуется никаких барьеров для защиты от возможных условий гонки, приводящих к повреждению памяти. Однако для того, чтобы это работало, сборщику мусора потребуется более подробная информация об использовании регистров, чем та, которую может предоставить компилятор, специально не предназначенный для взаимодействия с сборщиком мусора.

@einpoklum: Интересный аспект многих интегрированных в фреймворк сборщиков мусора, который многие люди не понимают, заключается в том, что битовые шаблоны, хранящиеся в ссылках, могут самопроизвольно изменяться при перемещении объектов. Перемещение GC на основе библиотеки потребует, чтобы ссылки на объекты содержали некоторый неизменный атрибут объекта, такой как адрес структуры, содержащей реальный адрес объекта, но интегрированный в структуру может хранить ссылки, используя прямые указатели, но затем, когда объекты получают перемещены, установите старые страницы в ловушку, а затем измените все ссылки, чтобы они удерживали новое местоположение.

Если предпринята попытка доступа к объекту, к объекту осуществляется доступ между временем, когда назначается новый адрес, и временем, когда ссылка, используемая для доступа, обновляется, обработчик прерывания может обнаружить, что ссылка содержит старый адрес объекта, обновить ссылку чтобы отразить новый адрес объекта, и повторите попытку доступа. Сборщики мусора, не интегрированные со средой выполнения, не могут использовать такие методы.

возможно, это лучший подход, который имеет преимущество обоих миров microsoft.com/en-us/research/publication/…