Zum Inhalt springen

„Real-Time Java“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
K →Entwicklung: weiterer
Die Technik heißt "Garbage Collection", der durchführende Codeteil "Garbage Collector". Nur von zweiterem kann es mehrere geben.
Zeile 4: Zeile 4:
Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)|Threads]] und [[Nebenläufigkeit]], machten eine direkte Verwendung von Java in harten Echtzeitsystemen unmöglich:
Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)|Threads]] und [[Nebenläufigkeit]], machten eine direkte Verwendung von Java in harten Echtzeitsystemen unmöglich:
* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].
* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].
* Das Verhalten bestimmter Java Garbage Collections kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.
* Das Verhalten bestimmter Java Garbage Collectors kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.


Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.
Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.
Zeile 11: Zeile 11:


== Entwicklung ==
== Entwicklung ==
Der seit Java 9 bei Servern standardmäßig eingesetzte Garbage first Garbage Collector (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>
Der seit Java 9 bei Servern standardmäßig eingesetzte „Garbage first Garbage Collector“ (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>


Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref><ref>[https://wiki.openjdk.java.net/display/zgc] The Z Garbage Collector - Sub-millisecond max pause times</ref>
Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref><ref>[https://wiki.openjdk.java.net/display/zgc] The Z Garbage Collector - Sub-millisecond max pause times</ref>

Version vom 27. Mai 2021, 09:05 Uhr

Real-Time Java ist eine Sammlung von Programmierschnittstellen, welche die Java-Technologie um harte Echtzeitfähigkeiten erweitert. Diese Real-Time Specification for Java (RTSJ) wurde als Java Specification Request 1 im Rahmen des Java Community Process entwickelt und als Standard im November 2001 verabschiedet. Aktuell wird an einer erweiterten Version der RTSJ im Rahmen des JSR 282 gearbeitet.[1]

Hintergründe

Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene Garbage Collection, sowie die native Unterstützung von Threads und Nebenläufigkeit, machten eine direkte Verwendung von Java in harten Echtzeitsystemen unmöglich:

  • Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf Prioritäten basierendes Threading-Modell. Damit unterstützen die Lock-Mechanismen von Java keine Mechanismen zur Vermeidung der Prioritätsinversion wie beispielsweise Prioritätsgrenzen oder Prioritätsvererbung.
  • Das Verhalten bestimmter Java Garbage Collectors kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.

Um diese Schwierigkeiten zu meistern wurde die Real-Time Specification for Java (RTSJ) als Java Specification Request entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die Java Virtual Machine durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.

Aktuelle Umsetzungen der RTSJ ermöglichen es, in Java harte und weiche Echtzeitanwendungen zu entwickeln. Zu den bekanntesten Implementierungen gehört die Referenzimplementierung von Timesys, IBMs WebSphere Real Time, Sun Microsystems Java SE Real-Time Systems, Aonix PERC und JamaicaVM von aicas.

Entwicklung

Der seit Java 9 bei Servern standardmäßig eingesetzte „Garbage first Garbage Collector“ (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.[2]

Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.[3][4][5][6]

Literatur

  • Eric J. Bruno, Greg Bollella: Real-Time Java™ Programming with Java RTS. Prentice Hall, 2009, ISBN 978-0-13-714298-9 (englisch, bvdep.com [abgerufen am 6. Dezember 2011]).
  • Peter C. Dibble: Real-Time Java Platform Programming. Prentice Hall, 2002, ISBN 978-0-13-028261-3 (englisch).
  • Andrew Wellings: Concurrent and Real-Time Programming in Java. John Wiley & Sons, 2004, ISBN 978-0-470-84437-3 (englisch).
  • Benjamin Brosgol, James Gosling, Peter Dibble, Steve Furr, David Hardin, Mark Turnbull: The Real-Time Specification for Java. Hrsg.: Gregory Bollella. Addison-Wesley Longman, 2000, ISBN 0-201-70323-8 (englisch).

Einzelnachweise

  1. ↑ https://jcp.org/en/jsr/detail?id=282
  2. ↑ [1] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013
  3. ↑ Metronome-GC-Algorithmus für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014
  4. ↑ [2] WebSphere Real Time in WebSphere Application Server
  5. ↑ https://www.azul.com/products/components/pgc/
  6. ↑ [3] The Z Garbage Collector - Sub-millisecond max pause times
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Real-Time_Java&oldid=212413290“