Seminar: Compiler-Konstruktion Realtime Java 1. Übersicht Echtzeitsysteme Warum Java? Java´s Echtzeitfähigkeit-Entwicklung Java´s Probleme und Lösungsansätze

1

Seminar:Compiler-Konstruktion

Realtime Java

2

Übersicht

• Echtzeitsysteme

• Warum Java?

• Java´s Echtzeitfähigkeit-Entwicklung

• Java´s Probleme und Lösungsansätze

• Anwendungen

•Fazit

3

Echtzeitsysteme

4

1. Echtzeitsysteme-Beispiele-

5

1. Echtzeitsysteme-Genaues Beispiel-

Airbag-Steuerung

ABS, ESP, usw.

Motormanagement

6

1. Echtzeitsysteme-Definition-

• In der Theorie: Computersystem, das ein Ergebnis innerhalb eines vorher fest definierten Zeitintervalls garantiert berechnet

• Ein Echtzeitsystem muss nicht nur ein Berechnungsergebnis mit dem richtigen Wert, sondern dasselbe auch noch rechtzeitig liefern

Falls dies nicht eingehalten wird, hat das System versagt

7

1. Echtzeitsysteme-Zeitschrankenarten-

• Einteilung der Zeitschranken:

• weiche Echtzeitanforderungen:Eine Überschreitung der Antwortzeit kann durchaus vorkommen, ist aber nicht kritisch

• harte Echtzeitanforderungen:Eine Überschreitung der Antwortzeit wir als Fehler gewertet. Das System liefert innerhalb einer festgelegten Zeitschranke seine Ergebnisse

8

1. Echtzeitsysteme-Eigenschaften-

Die Echtzeitfähigkeit eines mittels Software realisierten Echtzeitsystems muss einige Eigenschaften aufweisen:

• maximale Laufzeit eines Moduls muss berechenbar sein und darf nichtoder nur bedingt beeinflussbaren Faktoren unterliegen

• Bei Rekursion muss die maximale Rekursionstiefe, bei Schleifen die maximale Anzahl an Iterationen feststehen

• Ressourcenbedarf muss bekannt sein

• Das Verhalten bei drohender Zeitüberschreitung muss definiert und vorhersehbar sein

• Die Laufzeit von Betriebssystemaufrufen (und Routinen der Laufzeitumgebung) muss berücksichtigt werden

9

Warum Java?

10

2. Warum Java?-Gründe für Java-

• objektorientiert

• einfach

• interpretiert

• robust

• plattformunabhängig und portabel

• nebenläufig

11

2. Warum Java?-Java Architekturen-

12

Java´s Echtzeitfähigkeits-Entwicklung

13

3. Java´s Echtzeitfähigkeits-Entwicklung-History-

• Juni 1998: Unter der Führung des NIST (National Institute für Standards and Technology) sollten die Anforderungen für ein echtzeitfähiges Java erarbeitet werden

37 Firmen beteiligt Umsetzung der erarbeiteten Ergebnisse gelang nicht Bildung von 2 Gruppen:

SUN-Lizenznehmer und unabhängige Hersteller• Jahr 2000:

SUN mit: „Real-Time Specification for JAVA“ unabhängige Hersteller: „Real-Time Core Extensions for JAVA“ und „Real-Time Data Access“

14


• Vorschläge basieren auf: Definition von Objekten, die nicht der globalen Speicherplatzverwaltung unterliegen

Darauf arbeitenden echtzeitfähigen Routinen (nicht beeinflussbar vom Carbage Collectior, mit der Möglichkeit zur Unterbrechung)

• Unterschiede: Garant das Echtzeitroutinen keine Heap-Objekte manipulieren Hardwarezugriff

15


16

Java´s Probleme undLösungsansätze

17

4. Java´s Probleme und Lösungsansätze-Kritische Bereiche-

Java hat 4 kritische Bereiche:

• Speichermanagement

•Scheduling

•Hardwarezugriffe

•Synchronisation

18

4. Java´s Probleme und Lösungsansätze -Problem: Speichermanagement-

Die automatische Garbage Collection verhindert:• Speicherlöcher und• erspart eine eigene Speicherverwaltung

Haben wir schon gehört: Benutzt wird Mark & Sweep AlgorithmusHierbei gilt:

Die Zeit, die der Algorithmus benötigt, ist abhängig von der Anzahl der erreichbaren Objekte, der Anzahl der Objekte im Heap, der Performanz des Prozessors und der Qualität des implementierten Codes.

19

4. Java´s Probleme und Lösungsansätze -Problem: Speichermanagement-

Das Problem dabei:während des „Mark“ – Schrittes darf nicht unterbrochen werden

da sonst eventuell Markierungen fehlendeshalb: Anhalten der Verarbeitung des Java Programms in der

JVM (stop the world)

Vorgehensweise bringt ein Echtzeit-System sofort zu Fall

20

4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement-

• Größtes Problem: Unterbrechung durch Garbage Collection

• Trotz z.B. neuer Methoden und Unterbrechungsmöglichkeiten für die GC andere Wahl bei der RTSJ

• Lösung: Neue Speicherbereiche außerhalb des Heap-Speichers und unabhängig von GC

21


• heap Memory:Speicher entspricht dem Heap. Lebenszeit eines Objektes wird durch seine Sichtbarkeit begrenzt. traditionelle Speicherart der JavaVM

22


• physical Memory:Speicher wird für Objekte verwendet, die spezielle physikalische Speicherbereiche benötigen, z.B. DMA Adressbereich

23


• immortal Memory:Es werden hier Objekte abgelegt, die zur gesamten Laufzeit der Anwendung existieren- GC räumt hier nie auf. Bereich ist bis zum Ende der Anwendung belegt

24


• scoped Memory:Speicherart wird begrenzt durch die Lebenszeit eines Objektes auf dir vorhandenen Referenzen auf den/die Threads. Existiert keine Referenz mehr auf einen Thread im Speicher, wird dieser freigegeben

25


• Zusätzliche Unterteilung des ScopedMemory in: LTMemory (PhysicalLTMemory) VTMemory (PhysicalVTMemory)

• Unterscheiden sich in der benötigten Zeit, um eine Zuteilung des Speicherplatzes vorzunehmen

• LTMemory:Darf nur lineare Zeit (LT=Lineare Time) benötigen. Notwendig für absolut zeitkritischen Code

• VTMemory:Keine speziellen Beschränkungen (VT=Variable Time). Für zeitkritischen Code nicht geeignet

26


• Für neue Speicherbereiche gelten neue Regeln hinsichtlich der Referenzierung von Objekten Trotz Freiheitsgrade Robustheit der Java-Spezifikation behalten

• Einschränkungen beim referenzieren auf Objekte in den neuen Speichertypen zu beachten:

GrundsatzEine Variable darf zu keinem Zeitpunkt eine Referenz auf ein Objekt haben, welches von ihr selbst gelöscht werden kann.

27


• ScopedMemory-Bereich kann immer vor Objekten im Heap- und ImmortalMemory gelöscht werden, ist es nicht möglich auf Objekte in ihm zu referenzieren Wenn Referenz nicht im selben Scope liegt

• Ansonsten sind Referenzen unkritisch

28


• Jedoch eine wichtige Einschränkung: NoHeapRealtimeThrad kann den GC unterbrechen Da durch können Verweise im Heap „verloren gehen“

NoHeapRealtimeThread darf unter keinen UmständenReferenzen auf Objekte im Heap-Speicher halten,

egal in welchem Speichertyp er selbst erzeugt wurde

29


• Erzeugen eines Objektes im ImmortalMemroy

30


• Erzeugen eines Objektes im ScopedMemory

31

4. Java´s Probleme und Lösungsansätze -Problem: Scheduling-

• Prioritäten bei Threads sind in der Java-Spezifikation vorgesehen aber nur vage Anweisungen für das Scheduling

• Höher priorisierte Threads werden niedriger-priorisierten Threads vorgezogen

keine Garantie das höher priorisierte Threads ständig arbeiten

• Thread Priorisierung nicht für gegenseitigen Ausschluss geeignet

32

4. Java´s Probleme und Lösungsansätze -Lösung: Scheduling-

Die RTSJ fordert:•Preemptiven Scheduler mit festen Prioritäten und min. 28 Prioritätsleven für Echtzeit-Threads

• 10 Prioritätsleven für normale Java-Threads

Echtzeit-Threads sind Instanzen von:RealtimeThread sowie NoHeapRealtimeThreads

33


34


•RealtimeThreads:Priorität liegt über den normalen java.lang.Thread und unter den NoHeapRealtimeThread. Genaue Zuordnung durch RealtimeParamter getroffen. Eignet sich nur für weiche Echtzeitanforderungen

•NoHeapRealtimeThreadsThread kann nicht durch die Garbage Collection unterbrochen werden. Threadtyp ist für höchst zeitkritische Anforderungen gedacht. Damit bei Heapzugriffen keine Inkonsistenzen entstehen, darf nicht auf den Heap zugegriffen werden

35


36


• Erzeugen eines einfach Realtime Threads

37


• Ändern der eigenen Thread Priorität

38


• Ändern der eigenen Thread Priorität

39

4. Java´s Probleme und Lösungsansätze -Problem: Hardwarezugriffe-

• Ansteuerung von Aktoren ist eine der wichtigsten Anwendungen eines Echtzeitsystems Java Spezifikation erlaubt keine direkten Hardware-Zugriffe

• Kommunikation nur mit Geräten möglich, die Java kennt und implementiert

• Großes Hindernis für den Einsatz in industriellen Bereichen

40

4. Java´s Probleme und Lösungsansätze -Lösung: Hardwarezugriffe-

• Einzige Möglichkeit auf Hardware zuzugreifen, ist der direkte Zugriff auf den physikalischen Speicher

• Nicht zwingend ein Nachteil, da so selbst geschriebene Gerätetreiber Einzug in das Java-

System erhalten Kommunikation mit Geräten möglich, die keine Java

Schnittstelle bieten Kommunikation mit anderen Programmen über

Speicherbereich

41

4. Java´s Probleme und Lösungsansätze -Lösung: Hardwarezugriffe-

• Klasse RawMemoryAccess stellte alle Methoden bereit

• Nicht möglich, Java-Objekte per Befehl in einen Speicherbereich abzulegen

Manipulation erfolgt auf Bit-Ebene, durch setter und getter Methoden

byte-, word-, long- und multiplebyte-Werte gelesen und geschrieben werden

• Schutzmechanismen verhindern, das Speicher verändert werden kann, der von der JVM verwendet wird

42

4. Java´s Probleme und Lösungsansätze-Problem: Synchronisation-

• Zusammenhang: Scheduling und Garbage Collection

• Beruht auf blockierenden Protokollen (gegenseitiger Ausschluss)

Bei Synchronisation von zeitkritischen und zeitunkritischen Threads darf die Garbage Collection nie gestartet werden, um Verzögerungen im zeitkritischen Code zu verhindern

43

4. Java´s Probleme und Lösungsansätze-Lösung: Synchronisation-

• 3 Bereiche: Organisation von Threads Prioritätsumkehr Nicht blockierende Kommunikation zwischen Threads

• Organisation von Threads:Priority-Scheduler hat mehrere Threads gleicher Priorität die rechenbereit sind einer muss ausgewählt werdenDie RTSJ fordert eine FIFO für jedes Prioritätslevel

44


• Prioritätsumkehr:Falls innerhalb der Warteschlange eine niederpriorisierter Thread eine Ressource sperrt, tritt die Methode zur Vermeidung der Prioritätsumkehr in Kraft

• RTSJ fordert minimal die Implementierung des Priority Inhertiance Protocol

• Zusätzlich gibt es das Priorty Ceiling Protocol

• Beide Verfahren heben die Priorität des sperrenden Threads an, um dessen Abarbeitung zu beschleunigen

• Unterschied: Zeitpunkt

45


46


• Blockierende Kommunikation unter Threads:Betrifft synchronisierte Nachrichten zwischen NoHeapRealtimeThreads und RelatimeThreads bzw. normalen Threads

• Problem:Im Falle einer GC bei der Kommunikation, kann der NoHeapRealtimeThread Verzögerungen erfahren

• Lösung:RTSJ führt sogenannte wait free queues ein Warteschlange mit besonderen Eigenschaften

47


48

4. Java´s Probleme und Lösungsansätze -Asynchrone Ereignisse-

• In Echtzeitanwendungen ist die Ausführung einer bestimmten zeitkritischen Aktion an ein auslösendes Ereignis gebunden

• RTSJ bietet hierfür:Überwachung von internen (selbst programmierten) und externen (Signale, Interrupts, Timer) Eigenissen

• 2 Klassen zur Realisierung AsyncEvent:

Symbolisiert das zu überwaschende EreignisAsyncEventHandler:

Enthält den auszuführenden Code

49

5. Anwendungen

• Echtzeitbibliotheken im Modul javax.realtime.* gekapselt

• Kommerzielle Anbietung der implementierten RTSJ: JamaicaVM der aicas GmBH OVM Project mehrerer Universitäten und Firmen JRate von SourceForge Mackinac von Sun Aphelion von Apogee

• Projekte mit RTSJ:Golden Gate – Luft- und RaumfahrtDD(X) – Militärnetcentric battlefield – MilitärMackinca - Industrie

50

6. Fazit

• RTSJ stellt sinnvolle Erweiterung dar, um Java Echtzeitfähig zu machen

• Scheduling und GC stellen die größten Probleme dar

• Trotz aller vorgestellten Lösungen wird ein in Java realisiertes System nie die gleiche Performance besitzen, wie ein vergleichbares System in C++

• Real Time Java ist für Anwendungen prädestiniert, in dehnen JVM sowie Basisbibliotheken nicht ins Gewicht fallen und zum anderen sehr komplexe Systeme zu implementieren sind

• Beispiele: Militär, Telekommunikation und Luft-und Raumfahrt

Documents

Seminar: Compiler-Konstruktion Realtime Java 1. Übersicht Echtzeitsysteme Warum Java? Java´s Echtzeitfähigkeit-Entwicklung Java´s Probleme und Lösungsansätze