~ 1s Latenzkontroll-App: Ist das für Java geeignet?

Question

Bei meiner Arbeit haben wir kürzlich die Systemarchitektur für eine Steuerungsanwendung fertiggestellt, die eine maximale Latenz von ungefähr ein bis zwei Sekunden hat. Es wird auf kleinen ARM-On-Chip-Boxen verteilt, die über ein IP-LAN kommunizieren.

Wir erwarten zunächst, dass wir C oder C++ verwenden würden, da es sich um eine klassische Steuersystemsprache handelt. Nachdem wir besprochen haben, wie man die Anwendung implementiert, stellen wir fest, dass C++ eine recht begrenzte Anzahl von Bibliotheken hat, keine Introspektion aufweist und einige andere Eigenschaften aufweist, die die Entwicklung verlangsamen könnten. Mein Kollege schlug dann vor, dass Java für den Job geeignet sein könnte.

Ich habe wirklich Angst vor der Latenz eines GC für eine Control-App, und ich zögere auch, RAII zu löschen, da die App eine Menge externer Ressourcen (Sockets, Datei-Handles, Handles von extern) verwenden wird libs usw.).

Die Pro/con Liste ist zur Zeit wie folgt:

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 

Die Speicherfragmentierung mit parallelen GC erwähnt wurde in this AMD article

Ich würde gerne Java verwenden, wenn GC Latenz war kein Problem und wir könnte RAII bekommen. Deshalb habe ich mir auch andere Sprachen angesehen, die RAII haben und als gute Alternativen dienen könnten, und bisher habe ich festgestellt, dass D, Ada, VB, Perl, Python (C), PHP, Tcl und Lua etwas zu haben scheinen Art von Rückruf außerhalb des Bereichs. Meine spontane Reaktion, dass vielleicht D, Python und ADA für eine Control-App geeignet sein könnten. D und ADA sind meine Favoriten.

Also meine Frage ist: Haben Sie irgendwelche Empfehlungen zu diesem Thema? Ist Java eine praktikable Option, und wenn Sie irgendeine Sprache wählen könnten, was wäre es?

Answer 1

Der GC wird nur zum Wiederherstellen von Speicher von verworfenen Objekten verwendet. Entsorgen Sie sehr wenig Ressourcen und Sie erhalten sehr kleine, kürzere GCs.

Sie könnten viele Sockets, Dateigriffe, Griffe von externen Bibliotheken verwenden, aber wie schnell verwerfen Sie sie?

Ein vollständiger GC wurde entwickelt, um die Fragmentierung zu entfernen. Dies geschieht durch Kopieren des gesamten Speichers, so dass er kontinuierlich verwendet wird. Deshalb ist es teuer, deshalb möchten Sie diese minimieren, wenn die Latenz für Sie wichtig ist. Das heißt, wenn Ihre vollständigen GCs mehr als 100 ms benötigen, haben Sie ein ernsthaftes Leistungsproblem. Es sollte nicht so hoch sein.

IMHO, ich short Sie sollten in der Lage sein, ein Kontrollsystem mit einer Latenz zu entwickeln, die gut unter 10 ms ist, 99% + der Zeit.

Answer 2

Wahrscheinlich brauchen Sie ein Konzept, wenn Sie Java verwenden möchten, würde ich vorschlagen, ein einfaches Prototy- und einen Stresstest zu schreiben, um zu untersuchen, welche Latenzzeit Sie unter hoher Last während der Speicherbereinigung haben. Dann überprüfe die verschiedenen Sammlertypen, z. low pause collector.

Das RAII Argument verstehe ich nicht wirklich, in C++ ist es IMHO einfacher, Speicherlecks als in Java zu erstellen.

Answer 3

Ich würde von GC (sicherlich wie in jeder JVM ich gesehen habe) in einer solchen Umgebung bleiben. Du wirst für immer den Kopf gegen das Problem schlagen.

Allerdings wollte ich nur darauf hinweisen, dass das RAII-Argument sehr schwach erscheint - Sie benötigen Code-Reviews und andere Schulungen, um sicherzustellen, dass solche Probleme von Ihrem Team gut verstanden werden.Es ist ein sehr schlechter Grund, eine Sprache, die sonst angemessen ist, auszuschließen, da jede Sprache, die ein unerfahrener/weniger als stellarer Programmierer verpassen kann.

Ich fühlte von Ihrer Liste, dass Sie C# fehlten (ich denke mit Mono), wo Sie viel mehr Kontrolle haben, wenn Sie es brauchen. Ich weiß nicht, ob es für Ihre Umgebung geeignet ist, aber wenn Sie VB auf Ihrer Wäscheliste von Sprachen aufführen, war das ein offensichtliches Versehen.