Java RTS 2.0: Bei Echtzeit-Anwendungen Prioritäten setzen

Java Real-Time-System (RTS) 2.0 ist Suns vollständig konforme Implementierung der Branchenstandarderweiterungen für die Java-Plattform. Führt man eine normale Java-Anwendung unter Java RTS 2.0 aus, ändert sich im Prinzip nichts. Die Unterschiede fallen erst auf, wenn eine Echtzeit-Anwendung entwickelt werden muss. Es gibt allerdings signifikante Verbesserungen in der jüngsten Version von Java RTS.

Welche Features und Verbesserungen gibt es in Java RTS 2.0?

Ein entscheidendes Feature von Java RTS 2.0 ist eine äußerst praktische Methode für die Wiederverwendung von Speicher innerhalb von Java-Programmen. Mithilfe dieser Methode lässt sich festlegen, wie und wann Funktionen ausgeführt werden sollen – bis auf wenige Millisekunden genau.

Java RTS 2.0 bietet die folgenden Verbesserungen gegenüber der Vorgängerversion:

• verbessertes Determinieren lange laufender Anwendungen
• Anwendungsüberwachung, Management- und Fehlersuchfunktionen
• ein neuer Dtrace-Probe-Provider für Java RTS
• neues MXBean zum Umschalten zwischen deterministischem und Debugging-Modus
• geänderte Übernahme vererbter Zugriffskontrolle für NHRTs (No-Heap-Real-Time-Threads).
• kleinere Bugfixes

Zwei Verbesserungen in dieser neuen Version verdienen besonderes Augenmerk: die Echtzeit-Speicherbereinigung und die Fähigkeit, ein Prozessorset zu erstellen und zuzuordnen.

Eine Echtzeit-Speicherbereinigung einrichten

Das Hauptfeature von Java RTS 2.0 ist seine Echtzeit-Speicherbereinigung (Real-Time-Garbage-Collector = RTGC). Sie vereinfacht die Erstellung von Echtzeitlösungen sowie die Kontrolle und das Tuning von Anwendungen enorm. Man kann seine vorhandenen Java-Threads in Echtzeit-Threads (RTTs) umwandeln, indem man sie umbenennt. Die Semantik bleibt dabei erhalten. Danach lässt sich RTGC verwenden. Die Priorität des Threads kann höher eingestellt werden als die Priorität der Speicherbereinigung. Dadurch kommt sie einem nicht mehr ins Gehege. Das war bisher ein äußerst ärgerliches Problem bei zeitkritischen Anwendungen.

Java RTS 2.0 unterstützt zwei Arten von Speicherbereinigung: den RTGC und die serielle Speicherbereinigung, die nicht in Echtzeit arbeitet. Die standardmäßige Speicherbereinigung RTGC weist möglicherweise einen geringeren Durchsatz auf als die serielle Speicherbereinigung, besonders bei nur einem Prozessor. Für Anwendungen, bei denen es mehr auf den Durchsatz der Speicherbereinigung ankommt als auf die durch deren Ausführung bedingten Unterbrechungen, lässt sich RTGC mit der Option -XX:-UseRTGC deaktivieren. In diesem Fall wird die nicht in Echtzeit arbeitende serielle Speicherbereinigung verwendet. Alle Threads, außer NHRTs, können von Unterbrechungen durch die Speicherbereinigung betroffen sein.

Der RTGC ist nebenläufig, so dass er jederzeit zurückgestellt werden kann. Man muss dem RTGC nicht die höchste Priorität einräumen. Es gibt auch keine Momente, in denen sämtliche Threads einer Anwendung während der Durchführung der Speicherbereinigung aussetzen. Bei mehreren Prozessoren kümmert sich eine CPU um die Speicherbereinigung, während ein Anwendungs-Thread weiterhin von einer anderen CPU ausgeführt wird.

Der einzige Zeitpunkt, in dem der RTGC einen Thread an der Ausführung hindert, ist der Zugriff auf den Java-Stack eines bestimmten Threads. Darin sind die lokalen Variablen und Operatoren gespeichert. Deshalb ist die potenzielle Hauptquelle von Unterbrechungen für einen bestimmten Thread das Scannen seines Stacks. Da ein Thread nicht vom Scannen der Stacks anderer Threads beeinträchtigt wird, bleiben die Unterbrechungen für einen Thread geringer als bei nicht-nebenläufigen Speicherbereinigungen.

Weitere Informationen finden sich in der Anleitung zur Speicherbereinigung für Java RTS 2.0.