Mit Java RTS 2.0 lässt sich die zeitliche Abfolge von Prozessen entsprechend ihrer Wichtigkeit festlegen. Von Java-Anwendungen wird das normalerweise nicht unterstützt. Der Artikel stellt die zentralen Elemente der neuen RTS-Version vor.
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[1] für Java RTS 2.0. Für ein besseres zeitliches Verhalten bei Rechnern mit mehreren Prozessoren kann man ein Prozessorset erstellen, das für die ausschließliche Benutzung von Java RTS 2.0 reserviert ist. Es lässt sich auch ein separates Prozessorset zur exklusiven Verwendung der NHRTs und der RTTs von Java RTS 2.0 bestimmen. Diese Aufteilung der verfügbaren Prozessoren sorgt für ein optimales zeitliches Verhalten dieser Threads durch die Reduzierung von Cache-Thrashing-Effekten.
Um Java RTS 2.0 anzuweisen, die NHRTs einem vorhandenen, festgelegten Prozessorset zuzuweisen, verwendet man die Option XX:RTSJBindNHRTToProcessorSet=<Prozessorset_ID>. Die diesem Prozessorset zugewiesenen Prozessoren sollten alle auf no-intr eingestellt werden, um Latenz und Jitter zu minimieren. Danach gibt der Aufruf von Runtime.availableProcessors durch einen NHRT die Anzahl der in diesem Prozessorset verfügbaren Prozessoren aus. Die entsprechende Option RTSJBindRTTToProcessorSet bindet RTTs an ein vorhandenes festgelegtes Prozessorset.
Das Solaris-Betriebssystem ermöglicht es, die Prozessoren eines Rechners auf mehrere kleine Prozessorsets ohne Überschneidungen aufzuteilen. Prozessoren, die einem bestimmten Set zugewiesen sind, bleiben für die ausdrücklich mit diesem Set verbundenen Vorgänge reserviert. Ein neues Prozessorset lässt sich mit dem folgenden Befehl erstellen (Superuser-Berechtigung erforderlich):
# /usr/sbin/psrset -c created processor set <pset id>
Mit dem folgenden Befehl werden Prozessoren zu diesem neuen Set hinzugefügt:
# /usr/sbin/psrset -a <pset id> <cpu id>
Dabei bezieht sich <cpu id> auf einen der aktiven Prozessoren, die von folgendem Befehl angezeigt werden:
# /usr/sbin/psrinfo <cpu id> on-line since mm/dd/yyyy hh:mm:ss <cpu id> on-line since mm/dd/yyyy hh:mm:ss <cpu id> on-line since mm/dd/yyyy hh:mm:ss <cpu id> on-line since mm/dd/yyyy hh:mm:ss
Nun kann man wie folgt die Java RTS Virtual Machine anweisen, in dem neuen Prozessorset zu laufen:
# /usr/sbin/psrset -e <pset id> <Java RTS command line>Java RTS unterscheidet sich hinsichtlich der Funktionalität in einer Reihe von Aspekten von Java SE und der Java Hotspot VM. Es verfügt über Taktgeneratoren, Timer, Klasseninitialisierung, Speicherverwaltung und Scheduling. Darüber hinaus sind bestimmte Aspekte nur für Java RTS relevant, etwa Programmierungserwägungen, bestimmte Beschränkungen, Bugs oder Workarounds.
Es gibt auch generelle Unterschiede in der Art und Weise, wie sich Java RTS im Vergleich zur Java Hotspot VM verhält, unter anderem die folgenden:
- Die Standardwerte für die Befehlszeilenparameter wurden für Java RTS optimiert. Sie können sich daher von den Standardwerten der Java Hotspot VM unterscheiden. Die Standardwerte für -Xms und -Xmx wurden zum Beispiel für Java RTS erhöht.
- Sämtlicher Speicher, der mit den Parametern -Xms und -Xmx angegeben ist, wird bei der Initialisierung der Java Hotspot VM beansprucht und fixiert.
- Java RTS bietet nur begrenzte Unterstützung für die Überwachungs-, Management-, und Fehlersuche-Tools.
- Da es NHRTs gibt, erfasst die Speicherbereinigung niemals Klassen und eingebettete Strings. Die Echtzeit-Spezifikation für Java (RTSJ) verhindert außerdem, dass bei statischer Initialisierung zugewiesene Objekte von der Speicherbereinigung erfasst werden. Es gilt zu bedenken, dass solche Objekte solange im Speicher verbleiben, bis die Java Hotspot VM beendet ist.
- Java RTS bietet nur den Client-Compiler. Der Server-Compiler hängt von nichtdeterministischer Optimierung ab und wurde daher deaktiviert.
- Just-In-Time-(JIT-)Kompilierung erfolgt in Java RTS standardmäßig asynchron.
- Java RTS bietet die Implementierung von Varianten von Inline Caches und Virtual Method Inlining. Diese Varianten sind besonders zur Verwendung mit dem RTGC gedacht.
- Java RTS bietet nur die 32-Bit-Client-Version der Java Hotspot VM. Die 64-Bit-Version wird nicht unterstützt, und die Verwendung der Option -server hat keine Auswirkungen.
- Java RTS 2.0 wird derzeit auf einem Ultra-SPARC-Prozessor oder auf einer Sun-x86/x64-Plattform mit Solaris 10 (nur Update 3 oder 4) unterstützt. Java RTS 2.1 für Linux ist als Vorabversion verfügbar (nur für Echtzeit-Linux-Versionen): Suse Linux Enterprise Real Time 10 und Red Hat Enterprise MRG 1.0.
- Es wird unbedingt empfohlen, über mindestens zwei Prozessoren zu verfügen.
Weitere Informationen zu Java RTS:
- Real-Time Java: Eine Einführung[2]
- Real-Time Java Spezifikation (RTSJ 1.0) unter JSR-001[3]
- Real-Time Java Spezifikation - Update (RTSJ 1.1) unter JSR-282[4]
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/