Каковы недостатки использования коллекции мусора?

Question

Большинство современных языков построены в сборке мусора (GC). например Java, языки .NET, Ruby и т. Д. Действительно, GC упрощает разработку приложений разными способами.

Мне интересно знать ограничения/недостатки написания приложений на языках GCed. Предполагая, что реализация GC оптимальна, мне просто интересно, что мы можем ограничить GC, чтобы принять некоторые решения по оптимизации.

Answer 1

Основные недостатки использования сборщика мусора, на мой взгляд, являются:

1. Недетерминированные зачистка ресурсов. Иногда бывает удобно сказать: «Я закончил с этим, и я хочу, чтобы он очистился СЕЙЧАС». С помощью GC это обычно означает принуждение GC к очистке всего или просто подождать, пока он не будет готов - оба из них уберут некоторый контроль от вас как разработчика.

2. Потенциальные проблемы с производительностью, возникающие в результате недетерминированной работы ГХ. Когда GC собирает, обычно видны (маленькие) зависания и т. Д. Это может быть особенно проблематичным для таких вещей, как симуляции в реальном времени или игры.

Answer 2

Если вы уверены (хорошо) в своих навыках управления памятью, нет никакого преимущества.

Концепция была введена для минимизации времени разработки и из-за отсутствия экспертов в программировании, которые полностью поняли память.

Answer 3

Для .NET есть два недостатка, которые я вижу.

1) Люди предполагают, что GC знает лучше всего, но это не всегда так. Если вы делаете определенные типы распределений, вы можете заставить себя испытать некоторые действительно неприятные смерти от программ без прямого вызова GC.

2) Объекты размером более 85 тыс. Идут на LOH или крупную кучу объектов. Эта куча в настоящее время НИКОГДА не уплотняется, поэтому снова ваша программа может испытывать исключения из-за памяти, когда LOH недостаточно уплотнен, чтобы вы могли сделать другое распределение.

Оба этих ошибок приведены в коде, который я разместил в этом вопросе:

How do I get .NET to garbage collect aggressively?

Answer 4

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

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

Answer 5

Бери от C программиста ... это о стоимости/выгоды и надлежащего использования

Алгоритмы сбора мусора, такие как трехцветный/наценки и прогонки зачастую значительная задержка между а ресурс «потерян» и освобожден физический ресурс. В некоторых операционных средах GC фактически приостанавливает выполнение программы для выполнения сбора мусора.

Будучи долгое время C программист, я могу вам сказать:

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

b) Ручная бесплатная() сборка мусора время - Время, затрачиваемое на отладку, перевешивает миллисекундные паузы GC? Возможно, полезно использовать сбор мусора, если вы пишете игру, чем скажем встроенное ядро.

Но, если вы не можете позволить себе недостаток времени выполнения (правильные ресурсы, ограничения в режиме реального времени), тогда выполнение ручного распределения ресурсов, вероятно, лучше. Это может занять некоторое время, но может быть на 100% эффективным.

Попробуйте представить ядро ​​ОС, написанное на Java? или на .NET runtime с GC ... Просто посмотрите, сколько памяти JVM накапливается при запуске простых программ. Я знаю, что проекты такие, как это ... они просто заставляют меня чувствовать себя немного больным.

Просто имейте в виду, что мой linux box делает то же самое сегодня с 3 ГБ оперативной памяти, чем когда он имел 512 МБ памяти. Единственное различие заключается в том, что у меня работает моно/jvm/firefox и т. Д. Бизнес-кейс для GC ясен, но это все равно делает меня неудобным много времени.

Хорошие книги:

Dragon book (recent edition), Modern Compiler Implementation in C

Answer 6

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

Если процессоры должны были вернуться к дескрипторной системе дескриптора/указателя (аналогично используемой 80286, хотя в настоящее время больше не использовать 16-битные сегменты), было бы возможно сделать сборку мусора одновременно с другими операциями (если дескриптор использовался, когда GC хотел его переместить, задача с использованием дескриптора должна была быть заморожена, а данные были скопированы из старого адреса в новый, но это не должно длиться долго). Не уверен, что это когда-нибудь случится, хотя (кстати, если бы у меня были мои druthers, ссылка на объект была бы 32 бита, а указатель был бы ссылкой на объект плюс 32-битное смещение, я думаю, что это будет некоторое время, прежде чем появится необходимо для более чем 2 миллиардов объектов или для любого объекта за 4 концерта. Несмотря на закон Мура, если приложение будет иметь более 2 миллиардов объектов, его производительность, скорее всего, будет улучшена за счет использования объектов с меньшим количеством объектов. Если для приложения потребуется объект более 4 концертов, его производительность, вероятно, будет улучшена за счет использования большего количества объектов меньшего размера.)

Answer 7

Как правило, вывоз мусора имеет определенные недостатки:

• Сбор мусора потребляет вычислительные ресурсы при решении вопроса, что память должна быть освобождена, перестраивая факты, которые могут быть известны программисту. Штраф за удобство аннотации времени жизни объекта вручную в исходном коде - это накладные расходы, что часто приводит к снижению или неравномерности производительности. Взаимодействие с эффектами иерархии памяти может привести к тому, что эти накладные расходы будут невыносимыми при обстоятельствах, которые трудно предсказать или обнаружить при обычном тестировании.
• Точка, в которой фактический сбор мусора может быть непредсказуемым, приводит к тому, что киоски разбросаны по всей сессии. Непредсказуемые киоски могут быть неприемлемыми в средах реального времени, таких как драйверы устройств, при обработке транзакций или в интерактивных программах.
• Память может протекать, несмотря на наличие сборщика мусора, если ссылки на неиспользуемые объекты сами не утилизируются вручную. Это описано как утечка логической памяти. [3] Например, рекурсивные алгоритмы обычно задерживают выпуск объектов стека до завершения окончательного вызова. Кэширование и воспоминания, общие методы оптимизации, обычно приводят к таким логическим утечкам. Убеждение, что сбор мусора устраняет все утечки, заставляет многих программистов не защищать от создания таких утечек.
• В средах виртуальной памяти, типичных для современных настольных компьютеров, сборщику мусора может быть сложно заметить, когда сбор необходим, в результате чего большие объемы накопленного мусора, длинный, разрушительный фаза сбора и данные других программ поменялись ,
• Возможно, самая значительная проблема заключается в том, что программы, которые полагаются на сборщики мусора, часто демонстрируют плохую локальность (плохо взаимодействуют с кешем и системами виртуальной памяти), занимают больше адресного пространства, чем программа на самом деле использует в любой момент, и касаются иначе простаивающих страниц , Они могут сочетаться в феномене, называемом «обмолотом», в котором программа тратит больше времени на копирование данных между различными классами хранения, чем выполнение полезной работы. Они могут сделать невозможным для программиста обосновать влияние производительности на выбор дизайна, затрудняя настройку производительности. Они могут привести мусор сбора программ мешать другим программам конкурировать за ресурсы

Answer 8

Я заинтересован знать ограничения/недостатки написания приложений на GCed языках. Предполагая, что реализация GC оптимальна, мне просто интересно, что мы можем ограничить GC, чтобы принять некоторые решения по оптимизации.

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