Echtzeit mit JAVA

Ein Vorteil von JAVA soll eigentlich sein, daß es plattformübergreifend 
laufen kann, ein  Nachteil ist, daß es meist viel Speicher frisst und 
oft langsamer ist. Von Lizenzproblemen wie SUN+MS abgesehen wäre es gut, 
ein Echtzeitsystem zu haben was dann überall läuft.

Es bleibt jedoch die kleine Frage bei mir, ob das jeweilige 
Betriebssystem überhaupt Lust hat, JAVA das entsprechende ZEITFENSTER 
bedarfsgerecht zur Verfügung zu stellen. Sobald dann wegen Echtzeit 
größere Eingriffe ins jeweilige BS nötig sind, tauchen dann bei mir 
weitere Fragen zur Sicherheit auf. Deshalb hat wohl bisher jeder sein 
Süppchen gekocht.

http://de.wikipedia.org/wiki/Liste_der_Betriebssysteme#Eingebettete_und_Echtzeit-Betriebssysteme

Mit Java können keine harten Echtzeitanforderungen gewährleistet werden, 
da es einen Garbage Collector zum Aufräumen des Speichers verwendet und 
der ist mit den Anforderungen eines harten Echtzeitsystems nicht in 
Einklang zu bekommen...

>Mit Java können keine harten Echtzeitanforderungen gewährleistet werden,
>da es einen Garbage Collector zum Aufräumen des Speichers verwendet
Ich bin mir nicht sicher, ob man das so pauschal sagen kann. Der Garbage 
Collector läuft ja in der Regel niederprior. Wenn das System genug 
Reserven hat, sollte es damit doch zu keinem Speichermangel kommen!? 
Natürlich muss man entsprechend sorgfältig programmieren und optimieren; 
aber das ist ja immer so. Mehr als einen Speichermangel kann der GC doch 
nicht verursachen oder sehe ich da was falsch?

http://www.kertasarie.de/sites/eigenschaften/index.htm#echtzeit

"Implementierungen der Kertasarie VM stehen in diesem Bereich sowohl für 
Geräte der PalmOS Klasse als auch für iPaq-PDAs von Compaq zur 
Verfügung. Sie eignet sich aber auch sehr gut für die Integration in 
Mobiltelefone oder schnurlose Telefone."

Das nennt du harte Echtzeit. Ohne Worte....

Speicherorganisation / GC 
http://www.wikiservice.at/dse/wiki.cgi?GarbageCollection ist eine Sache.
Aber wer garantiert, das jedes darunterliegende Betriebssystem JAVA 
überhaupt ein Zeitfenster zur rechten ZEIT freigibt??

Java, RT OS und RT GC müssen natürlich zusammenpassen. Für Java soll es 
sowas geben, für .NET hätte ich das auch gerne. Aber Java für RT 
Aufgaben macht nur dann Sinn wenn man schon eine vorhandene Codebasis in 
Java hat oder die Programmiertruppe nur Java beherscht. Sonst ist 
Standard C/C++ sicher am weitesten verbreitet für RT Programmierung.

> Aber Java für RT Aufgaben macht nur dann Sinn wenn man schon eine
> vorhandene Codebasis in Java hat oder die Programmiertruppe nur Java
> beherscht. Sonst ist Standard C/C++ sicher am weitesten verbreitet für
> RT Programmierung.

Das ist der Punkt: Die meisten Java-Programmierer können von Natur gut
Web- und Geschäftsanwendungen entwickeln, haben aber mit RT-Program-
mierung nicht viel Erfahrung. Richtig RT programmieren zu lernen dauert
deutlich länger als von Java auf C umzusteigen. Java auf Echtzeit
aufzupimpen hat also nur einen beschränkten Nutzen.

Und wenn man für Benutzerschnittstelle, Netzwerkanbindung u.ä. Java
bevorzugt, kann man die echtzeitkritischen Teile ja trotzdem in C oder
C++ implementieren.

@Jürgen G.
Das ist schwer zu glauben, denn Java nutzt auch bloss die WindowsApi 
dann anders kommt man an die schnittstelle nicht ran. Und wie eine 
zusätzliche Software die geschwindigkeit erhöhen soll ist mir nicht 
klar.
Ich vermute mal der Fehler lag in dem C Programm.

Jürgen G. wrote:
>So nahm ich Java. Das ging bedeutend (5x !) schneller.

Java nutzt ja bekanntlich eine VM, um den plattformunabhänigen Bytecode 
in den zielgerät-spezifischen Binärcode umzusetzen. Die VM setzt dabei 
immer auf den API's des jeweiligen Zielsystems auf. D.h.: Java nutzt 
auch nur die Windows-API. Durch Just-In-Time-Compiler kann Java sehr 
schnell werden; in etwa so schnell wie gut optimierte C/C++-Programme. 
Wenn Deine Java-Applikation allerdings 5x schneller als Dein C-Programm 
war, war Dein C-Programm miserabel optimiert (Optimierung des 
C-Compilers ausgeschaltet ???).

Gruß,
Rayk

oops, da waren wieder zwei schneller...
>Einfach, indem man in den Scheduler von Windows eingreift.
Jürgen, das relativiert Deine Aussage wieder...
(Wenn die VM das kann, dann kann das Dein C-Programm auch ;o) , und 
damit hätte das C-Programm bestimmt die Nase vorn gehabt...)

Nur mal zum Thema GarbageCollector:

Kassenanwendung einer großen Bank, Testweise mal in Java.
Nach ein Paar Tagen meldeten einige Filialen, dass das Programm sich 
aufgehängt hatte.

Nach Intensiven Tests stellte sich heraus das es der Garbagecollector 
schuld war:

Auf den Testrechnern sammelten sich sage und schreibe 12 Gigabyte (!!!) 
im RAM an, bis der GC mal loslegte. Das die PC´s in den Filialen das 
nicht bewältigen konnten ist natürlich klar.

Nach etlichen Stunden lief das Programm dort natürlich weiter als wäre 
nichts gewesen...

> Auf den Testrechnern sammelten sich sage und schreibe 12 Gigabyte (!!!)
> im RAM an
Welch ein Kassensystem hat 12GB RAM?

> Das Problem lag m.E. an der Tatsache, dass meine Callback-Routine
> (welche empfangene Daten verarbeitet) nicht unmittelbar nach dem
> Dateneingang aufgerufen wurde, sondern erhebliche Zeit spaeter,
So etwas macht nicht mal Windows. Wenn du wartest bis Daten vorhanden 
sind und dann das Zeichen abrufst danach deine Callback aurufst, dann 
ist die Zeitscheibe von deinem Thread gerantiert nicht abgelaufen. Das 
ganze sollte weniger als 1ms dauern.
Der Scheduler entzieht dir bloss deine Rechenzeit wenn du sie bis zum 
ende ausreizt. Wenn aber Daten ohne grosse berechnung von der Seriellen 
Empfangen werden dann langweilt sich der Rechner. Und Sobald dein Thread 
auf das nächste Zeichen wartet, gibt du selber die Rechenzeit ab. Damit 
ist es völlig egal auf welches Timing im scheduler eingestellt ist.

wenn der GC das problem ist, ruf' das teil einfach explizit auf, dann 
gibt's nicht so viel datenmüll.

zum C programm, hast du das terminal auch richtig konfiguriert, alle 
buffer aus und so weiter?

>Welch ein Kassensystem hat 12GB RAM?
Schonmal was von Virtuellem Arbeitsspeicher gehört? Ziemlich langsam, 
aber funktioniert...

Die 12GB wurden auf einem der Entwicklungsrechner gemessen, die haben 
etwas mehr RAM :-)

>Auch ein GC kann nicht zaubern. Viele Java-Programmierer scheinen zu
>meinen, mit einem GC braucht man sich um nichts mehr zu kümmern und kann
>ohne Sinn und Verstand Speicher verschwenden, der GC wird's schon
>richten. Das klappt nicht.

Der GC wurde zwischendurch immer wieder extra aufgerufen.
In einem Testprogramm zum GC stellte sich aber heraus, das der GC nicht 
unbedingt auf das Programm hört. Er wurde korrekt aufgerufen und machte 
meistens alles richtig, manchmal aber auch einfach NICHTS...

>Er wurde korrekt aufgerufen und machte meistens alles richtig,
>manchmal aber auch einfach NICHTS...

Tja, dem GC wird manchmal auch etwas zuviel zugemutet. Der GC muss ja im 
Prinzip jedes angelegt Objekt prüfen, ob noch Referenzen darauf 
existieren. Sind noch Referenzen vorhanden müssen diese geprüft werden. 
Existieren "rekursive" Referenzen, kann so mancher GC den Objekt-Klops 
nicht entsorgen.

Java-Programmierer vergessen manchmal, dass man dem GC etwas unter die 
Arme greifen sollte: nicht mehr benötigte Referenzen werden auf 'null' 
gesetzt. Und schon hat der GC viel weniger tun!

Es ist also kein Problem des GC sondern einer schlampigen 
Programmierung!

>Auch ein GC kann nicht zaubern. Viele Java-Programmierer scheinen zu
>meinen, mit einem GC braucht man sich um nichts mehr zu kümmern und kann
>ohne Sinn und Verstand Speicher verschwenden, der GC wird's schon
>richten. Das klappt nicht.

Genau das ist das Problem!

>> Welch ein Kassensystem hat 12GB RAM?
> Schonmal was von Virtuellem Arbeitsspeicher gehört? Ziemlich langsam,
> aber funktioniert...
Nach dem Senden fiel mir das auch ein... ;-)