Большинство современных языков построены в сборке мусора (GC). например Java, языки .NET, Ruby и т.д. Действительно, GC упрощает разработку приложений разными способами.
Мне интересно знать ограничения/недостатки написания приложений на языках GCed. Предполагая, что реализация GC оптимальна, мне просто интересно, что мы можем ограничить GC, чтобы принять некоторые решения по оптимизации.
Основными недостатками использования сборщика мусора, на мой взгляд, являются:
Недетерминированная очистка ресурсов. Иногда бывает удобно сказать: "Я закончил с этим, и я хочу, чтобы он очистился СЕЙЧАС". С GC это обычно означает принуждение GC к очистке всего или просто подождать, пока он не будет готов - оба из них уберут некоторый контроль от вас как разработчика.
Потенциальные проблемы с производительностью, возникающие в результате недетерминированной работы ГХ. Когда GC собирает, обычно видны (маленькие) зависания и т.д. Это может быть особенно проблематичным для таких вещей, как моделирование в реальном времени или игры.
Возьмите его с программиста C... речь идет о стоимости/пользе и соответствующем использовании
Алгоритмы сбора мусора, такие как tri-color/mark-and-sweep, часто имеют значительную задержку между "потерянным" ресурсом и освобождаемым физическим ресурсом. В некоторых режимах работы GC фактически приостанавливает выполнение программы для выполнения сбора мусора.
Будучи программистом на длительный срок, я могу сказать вам:
a) Сбор данных мусора вручную() невелик. Это связано с тем, что при размещении свободных() вызовов в телефоне, чем алгоритмы GC, обычно наблюдается большая ошибка.
b) Ручное бесплатное() время сбора мусора время. Проводится ли время отладки перерывами миллисекундных пауз GC? Возможно, полезно использовать сбор мусора, если вы пишете игру, чем скажем встроенное ядро.
Но, когда вы не можете позволить себе недостаток времени выполнения (правильные ресурсы, ограничения в режиме реального времени), то, возможно, лучше выполнить ручное распределение ресурсов. Это может занять время, но может быть на 100% эффективным.
Попробуйте представить себе ядро ОС, написанное на Java? или на .NET runtime с GC... Просто посмотрите, сколько памяти JVM накапливается при запуске простых программ. Я знаю, что проекты существуют вот так... они просто заставляют меня чувствовать себя немного больным.
Просто имейте в виду, что мой linux box делает то же самое сегодня с 3 ГБ оперативной памяти, чем когда он имел 512 МБ памяти. Единственное различие заключается в том, что у меня работает моно /jvm/firefox и т.д. Бизнес-кейс для GC ясен, но он все равно делает мне неудобным много времени.
Хорошие книги:
Книга дракона (последнее издание), Современная реализация компилятора в C
Для .NET есть два недостатка, которые я вижу.
1) Люди предполагают, что GC знает лучше всего, но это не всегда так. Если вы делаете определенные типы распределений, вы можете заставить себя испытать некоторые действительно неприятные смерти от программ без прямого вызова GC.
2) Объекты размером более 85 К переходят в LOH или Large Object Heap. Эта куча в настоящее время НИКОГДА не уплотняется, поэтому снова ваша программа может испытывать исключения из-за памяти, когда действительно LOH недостаточно уплотнен, чтобы вы могли сделать другое выделение.
Обе эти ошибки отображаются в коде, который я опубликовал в этом вопросе:
Мне интересно знать ограничения/недостатки написания приложений на языках GCed. Предполагая, что реализация GC оптимальна, мне просто интересно, что мы можем ограничить GC, чтобы принять некоторые решения по оптимизации.
Я убежден, что автоматическое управление памятью накладывает стеклянный потолок на эффективность, но у меня нет доказательств, подтверждающих это. В частности, сегодня алгоритмы GC предлагают только высокую пропускную способность или низкую задержку, но не оба одновременно. Производственные системы, такие как .NET и JSM HotSpot, вызывают значительные паузы именно потому, что они оптимизированы для пропускной способности. Специализированные алгоритмы GC, такие как Staccato, предлагают значительно более низкую задержку, но за счет гораздо более низкого использования минимального мутатора и, следовательно, низкой пропускной способности.
Если вы уверены (хорошо) в своих навыках управления памятью, нет никаких преимуществ.
Концепция была введена для минимизации времени разработки и из-за отсутствия экспертов в программировании, которые полностью поняли память.
Самая большая проблема, связанная с производительностью (особенно в системах реального времени или в режиме реального времени), заключается в том, что ваша программа может столкнуться с некоторыми неожиданными задержками при запуске GC. Однако современный GC пытается избежать этого и может быть настроен для реального времени целей.
Еще одна очевидная вещь: вы не можете самостоятельно управлять своей памятью (например, выделять локальную память numa), что вам может понадобиться при реализации низкоуровневого программного обеспечения.
Почти невозможно сделать диспетчер памяти без GC работать в многопроцессорной среде, не требуя, чтобы блокировка была получена и выпущена каждый раз, когда выделена или освобождена память. Каждый захват или выпуск блокировки потребует, чтобы процессор координировал свои действия с другими ЦП, и такая координация имеет тенденцию быть довольно дорогостоящей. Система, основанная на мусоросборнике, может позволить много распределений памяти, не требуя каких-либо блокировок или другой координации между ЦП. Это важное преимущество. Недостатком является то, что многие шаги в сборке мусора требуют, чтобы ЦП координировал свои действия, и получение хорошей производительности обычно требует, чтобы такие шаги были в значительной степени консолидированы (не так много преимуществ для устранения требования координации ЦП по каждому распределению памяти, если ЦП должны согласовывать перед каждым шагом сборки мусора). Такая консолидация часто приводит к тому, что все задачи в системе должны приостанавливаться в течение различной продолжительности времени во время сбора; в общем, чем дольше паузы, которые готовы принять, тем меньше времени потребуется для сбора.
Если процессоры должны были вернуться к дескрипторной системе дескриптора/указателя (аналогично используемой 80286, хотя в настоящее время больше не будут использовать 16-битные сегменты), можно было бы сделать сборку мусора одновременно с другими операциями (если дескриптор использовался, когда GC хотел его переместить, задача с использованием дескриптора должна была быть заморожена, когда данные были скопированы со старого адреса на новый, но это не должно длиться долго), Не уверен, что это когда-нибудь случится, хотя (кстати, если бы у меня были мои druthers, ссылка на объект была бы 32 бита, а указатель был бы ссылкой на объект плюс 32-битное смещение, я думаю, что это будет некоторое время, необходимо для более чем 2 миллиардов объектов или для любого объекта за 4 концерта. Несмотря на закон Мура, если приложение будет иметь более 2 миллиардов объектов, его производительность, скорее всего, будет улучшена за счет использования объектов с меньшим количеством объектов. Если для приложения потребуется объект более 4 гигабайт, его производительность, вероятно, будет улучшена за счет использования большего количества объектов меньшего размера.)
Как правило, сбор мусора имеет определенные недостатки: