Является ли сборщик мусора (.net / java) проблемой для систем реального времени?

Question

При построении системы, которая должна реагировать очень последовательно и быстро, есть ли потенциальная проблема с сборщиком мусора?

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

Мы пройдем еще несколько лет, но мне интересно, если это все еще проблема.Я читал о новом сборщике мусора в .Net 4, но он все еще выглядит как большой черный ящик, и вы просто должны верить, что все будет хорошо.

Если у вас есть система, которая всегда должнабудьте быстры, чтобы ответить, сборщик мусора является слишком большой проблемой, и лучше ли выбрать более хардкорный, управлять им самим таким языком, как c ++?Я бы не хотел, чтобы, если это оказалось проблемой, вы практически ничего не могли с этим поделать, кроме как ждать новой версии среды выполнения или делать очень странные вещи, чтобы попытаться повлиять на сборщик.

РЕДАКТИРОВАТЬ

спасибо за все большие ресурсы.Однако, похоже, что большинство статей / пользовательских gc / решений относятся к среде Java..Net также имеет возможности настройки или опции для пользовательского GC?

Answer 1

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

Более подробную информацию можно найти в Спецификации реального времени для Java об одном из подходов к достижению поведения в реальном времени с использованием Java. Идея RTSJ очень проста - не использовать кучу. RTSJ предоставляет новые разновидности объектов Runnable, которые гарантируют, что потоки не получат доступ к памяти кучи любого вида. Потоки могут получать доступ к памяти с областью действия (ничего необычного; значения уничтожаются при закрытии области действия) или к бессмертной памяти (которая существует в течение всего времени жизни приложения). Переменные в бессмертной памяти перезаписываются снова и снова с новыми значениями.

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

Более подробная информация доступна в статье "Проект Золотые Ворота: к Java в реальном времени в космических полетах", опубликованной JPL и Sun .

Answer 2

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

Единственное, что я бы не хотел использовать Java / .NET для сбора мусора, это что-то вроде встроенного программирования с жесткими ограничениями в реальном времени (например, контроллеры движения).

Тем не менее, вам необходимо знать о паузах ГХ, и все перечисленное может быть полезным для минимизации риска пауз ГХ:

• Минимизация выделения новых объектов - хотя распределение объектов в современных системах GC чрезвычайно быстрое, они вносят вклад в будущие паузы, поэтому их следует минимизировать. Вы можете использовать такие методы, как предварительное выделение массивов объектов, хранение пулов объектов или использование неупакованных примитивов.
• Используйте специализированные библиотеки с малой задержкой, такие как Javalution для интенсивно используемых функций и типов данных. Они разработаны специально для приложений реального времени / с малой задержкой
• Убедитесь, что вы используете лучший алгоритм GC, когда доступно несколько версий. Я слышал хорошие отзывы о Sun G1 Collector для приложений с низкой задержкой. Лучшие GC-системы выполняют большую часть своих сборок одновременно, поэтому сборкам мусора не нужно «останавливать мир» очень долго, если вообще.
• Настройте параметры ГХ соответствующим образом. Обычно есть компромисс между общей производительностью и временем паузы, вы можете улучшить последнее за счет первого.

Если вы очень богаты, вы, конечно, можете купить машины с аппаратной поддержкой GC . : -)

Answer 3

Да, мусор должен обрабатываться детерминистически в системах реального времени.

Один из подходов заключается в планировании определенного количества времени для сборки мусора во время каждого выделения памяти. Это называется «сборка мусора на основе работы». Идея заключается в том, что при отсутствии утечек распределение и сбор должны быть пропорциональными.

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

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

Answer 4

С теоретической точки зрения сборщики мусора - это не проблема , а решение .Системы реального времени сложны, когда есть динамическое распределение памяти.В частности, обычные функции C malloc() и free() не предоставляют гарантий в реальном времени (они обычно бывают быстрыми, но имеют, по крайней мере теоретически, «наихудшие случаи», когда они используют непомерное количество времени).

Так получилось, что можно построить динамический распределитель памяти, который предлагает гарантии в реальном времени, но для этого требуется, чтобы распределитель выполнял некоторые тяжелые действия, в частности, перемещал некоторые объекты в ОЗУ.Перемещение объектов подразумевает корректировку указателей (прозрачно, с точки зрения кода приложения), и на этом этапе распределитель находится всего в одном небольшом шаге от сборщика мусора.

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

Также обратите внимание, что обычные реализации Java или .NET выполняются в операционных системах, которые не являютсялибо в режиме реального времени (ОС может принять решение о планировании других потоков, либо может агрессивно отправить некоторые данные в файл подкачки и т. д.), и ни одно из них не является базовым оборудованием (например, обычный жесткий диск может делать «паузы перекалибровки» вовремяко времени).Если вы готовы терпеть случайный сбой синхронизации из-за аппаратного обеспечения, то у вас должно быть все в порядке с (тщательно настроенным) сборщиком мусора JVM.Даже для игр.

Answer 5

Вы уверены, что это проблема. Если вы пишете приложения с низкой задержкой, вы не можете позволить себе stop-the-world пауз, которые навязывает большинство сборщиков мусора. Поскольку Java не позволяет вам отключать GC, вы можете не создавать мусор. Это можно сделать и было сделано с помощью пула объектов и начальной загрузки. Я написал статью в блоге , где подробно об этом говорю.

Answer 6

Это потенциальная проблема, НО ...

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

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

Answer 7

В нашей компании используется большое программное приложение на основе .Net, которое, помимо прочего, контролирует двоичные датчики в сетях полевой шины. В некоторых ситуациях датчики активируются только на короткое время (300 мс), но нашему программному обеспечению все еще необходимо фиксировать эти события, так как контролируемая система сразу же потерпит неудачу, если событие пропущено. Недавно мы наблюдали увеличение проблем на сайтах наших клиентов из-за сборщика мусора, работающего в течение длительного времени (до 1 секунды). Мы все еще пытаемся выяснить, как установить ограничение времени для сборщика мусора. В заключение этого короткого рассказа я бы сказал, что сборщик мусора является помехой для приложений, критичных ко времени.