~1s latency control app: is this suitable for Java?

At my work we recently finished the system architecture for a control application which has a maximum latency of roughly one to two seconds. It is distributed on small ARM on-chip boxes communicating via an IP LAN.

We initially foresee that we would use C or C++, since it is a classical control system language. After discussing how to implement the application we now realize that C++ has a quite limited amount of libraries, lacks introspection, and has some other properties which might slow down development. My colleague then suggested that Java might be up for the job.

I'm really scared about the latency of running a GC for a control app, and I'm also reluctant to dro开发者_StackOverflow中文版p RAII, since the app will use a lot of external resources (sockets, file handles, handles from external libs etc).

The pro/con list is currently as follows:

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

The memory fragmentation with parallel GC was mentioned in this AMD article

I would love to use Java if GC latency wasn't a problem and we could get RAII. Therefore I've also looked into other langs which have RAII and could serve as good alternatives, and so far I've found that D,Ada,VB,Perl,Python(C),PHP,tcl and Lua seem to have some sort of out-of-scope callback. My spontainous reaction that perhaps D, Python, and ADA could be suitable for a control app. D and ADA are my favourites.

So, my question is: do you have any recommendations on this? Is Java a viable option, and if you could choose any language, what would it be?

Probably you need a prove of concept if you wish to use java, I would suggest to write a simple prototye and a stress test, to examine what latency time you have under high load during garbage collection. Then checkout the different collector types i.g. low pause collector .

The RAII argument I don't really understand, in c++ it's IMHO easier to create memory leaks than in java.

The GC is only used for reclaiming memory from discarded objects. Discard very little resources and you will get very little, shorter GCs.

You might use lots of sockets, file handles, handles from external libs, but how fast do you discard them?

A full GC is designed to remove fragmentation. It does this by copying all the memory so it is used continously. This is why its is expensive, so you want to minimise these if latency is important to you. That said, if your full GCs are taking more than 100 ms, you have a serious performance issue. It shouldn't be that high.

IMHO, I short you should be able to develop a control system with a latency which is well under 10 ms, 99%+ of the time.

I would stay away from GC (certainly as implemented in any JVM I have seen) in such an environment. You will forever be banging your head against the wall on the problem.

However, I just wanted to point out that the RAII argument seems very weak - you need code reviews and other such training to ensure that such issues are well understood by your team. It is a very bad reason to exclude a language that is otherwise appropriate, as every language has gotchas that an inexperienced/less than stellar programmer can miss.

I felt from your list that you were missing C# (I'm thinking of with Mono) where you have a lot more control when you need it. I don't know if it is appropriate for your environment, but if you list VB on your laundry list of languages, it was an obvious oversight.