Выбор JVM для встроенного потокового устройства

Question

Мы разрабатываем устройство, которое в основном представляет собой raspberry pi, которое считывает данные файла, обрабатывает их и передает данные с устройства USB с заданной частотой кадров.

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

Сейчас мы используем HotSpot JVM, но, насколько я понимаю, он лучше подходит для больших размеров кучи, наша память редко превышает 256 МБ, поэтому мне интересно, есть ли лучшая виртуальная машина с сборкой мусора, которая может дать нам паузы менее 15 мс на Raspberry Pi?

Answer 1

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

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

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

Answer 2

Я думаю, вы действительно будете бороться с этим. Вы не предоставляете флаги, которые используете для запуска своей JVM, поэтому нет возможности рекомендовать альтернативы.

Хорошо сконфигурированный коллектор G1 с приложением, которое не генерирует постоянно увеличивающиеся объекты с длительным сроком службы, позволит избежать полных сборщиков мусора. Однако ваша проблема в том, что даже незначительные сборщики мусора (которые обычно очень быстрые) вызывают недопустимую задержку. Частично проблема заключается в скорости шины памяти на Pi, которая на самом деле не так уж велика.

Мы (Азул, на которого я работаю) производим сборщик без пауз (C4), но он предназначен для машин с большим количеством ресурсов. Для этого требуется минимум 1 ГБ ОЗУ и несколько ядер для одновременной обработки GC с потоками приложений.