~ 1s приложение контроля задержки: это подходит для Java?

Question

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

Изначально мы предвидели, что будем использовать C или C ++, поскольку это классический язык системы управления. После обсуждения того, как реализовать приложение, мы теперь понимаем, что C ++ имеет довольно ограниченное количество библиотек, не имеет интроспекции и обладает некоторыми другими свойствами, которые могут замедлить разработку. Мой коллега тогда предположил, что Java может подойти для этой работы.

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

Список pro / con в настоящее время выглядит следующим образом:

C++

+ RAII - Easy resource management - it will be a complex system
+ System language - speed if we cant't find a JIT VM for our ARM
+ No GC - no big worst case latencies from the GC
+ Easy to integrate with some shared mem libs that we have to interface with
- Fewer free as in beer libs 
- Lacks introspection - Mapping classes to DB and external data formats (XML)    
  would benefit from this (ORM /JAXB) approach
- Easy to shoot one self in the foot - hard and expensive to find programmers 
  which don't make big mistakes
- Memory fragmentation - needs tuning and workarounds

Java

+ Huge amount of libs
+ Introspection - serialization becomes a breeze (see C++ section)
+ Easier to find 'good enough' programmers
- No RAII - Client has to remember finally or you leak 
   resources. IMO Java programmers tend to ignore this 
   problem unless they have server app background.
- No System Language - possibly slower although ARMj could alleviate this
- GC - latency might go up (don't know if parallel GC will work - seems that
     you might get fragmentation, see note below).
- Need to write JNI for the shared mem libs that we interface with
- Maybe ORACLE will eat us

Фрагментация памяти с параллельным GC была упомянута в этой статье AMD

Я бы хотел использовать Java, если задержка GC не была проблемой, и мы могли бы получить RAII. Следовательно Я также изучил другие языки, которые имеют RAII и могли бы послужить хорошей альтернативой, и до сих пор я обнаружил, что D, Ada, VB, Perl, Python (C), PHP, tcl и Lua, похоже, имеют своего рода Вне области обратного вызова. Моя спонтанная реакция на то, что, возможно, D, Python и ADA могут подойти для приложения управления. D и ADA мои любимые.

Итак, мой вопрос: есть ли у вас какие-либо рекомендации по этому поводу? Является ли Java жизнеспособным вариантом, и если бы вы могли выбрать какой-либо язык, каким он был бы?

Answer 1

Вероятно, вам понадобится подтверждение концепции, если вы хотите использовать Java, я бы предложил написать простое прототип и стресс-тест, чтобы проверить, какое время задержки у вас под высокой нагрузкой во время сбора мусора. Затем проверьте различные типы коллекторов, например Коллектор с низкой паузой .

Аргумент RAII Я не очень понимаю, в c ++ ИМХО легче создавать утечки памяти, чем в Java.

Answer 2

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

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

Answer 3

ГХ используется только для восстановления памяти из отброшенных объектов. Откажитесь от очень маленьких ресурсов, и вы получите очень маленькие, более короткие GC.

Вы можете использовать множество сокетов, файловых дескрипторов, дескрипторов внешних библиотек, но как быстро вы их отбрасываете?

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

ИМХО, коротко, у вас должна быть возможность разработать систему управления с задержкой, которая значительно меньше 10 мс, 99% + времени.