Seminar: Compiler-Konstruktion

Seminar: Compiler-Konstruktion
Realtime Java

Übersicht Echtzeitsysteme Warum Java?
Java´s Echtzeitfähigkeit-Entwicklung Java´s Probleme und Lösungsansätze Anwendungen Fazit

Echtzeitsysteme

1. Echtzeitsysteme -Beispiele-

1. Echtzeitsysteme -Genaues Beispiel-
Airbag-Steuerung Motormanagement ABS, ESP, usw.

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

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

1. Echtzeitsysteme -Eigenschaften-
Die Echtzeitfähigkeit eines mittels Software realisierten Echtzeitsystems muss einige Eigenschaften aufweisen: maximale Laufzeit eines Moduls muss berechenbar sein und darf nicht oder 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

Warum Java?

2. Warum Java? -Gründe für Java-
objektorientiert einfach interpretiert robust plattformunabhängig und portabel nebenläufig

2. Warum Java? -Java Architekturen-

Java´s Echtzeitfähigkeits- Entwicklung

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“

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

Java´s Probleme und Lösungsansätze

4. Java´s Probleme und Lösungsansätze -Kritische Bereiche-
Java hat 4 kritische Bereiche: Speichermanagement Scheduling Hardwarezugriffe Synchronisation

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 Algorithmus Hierbei 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.

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 fehlen deshalb: Anhalten der Verarbeitung des Java Programms in der JVM (stop the world) Vorgehensweise bringt ein Echtzeit-System sofort zu Fall

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

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

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

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

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

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

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: Grundsatz Eine Variable darf zu keinem Zeitpunkt eine Referenz auf ein Objekt haben, welches von ihr selbst gelöscht werden kann.

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

Jedoch eine wichtige Einschränkung:  NoHeapRealtimeThrad kann den GC unterbrechen  Da durch können Verweise im Heap „verloren gehen“ NoHeapRealtimeThread darf unter keinen Umständen Referenzen auf Objekte im Heap-Speicher halten, egal in welchem Speichertyp er selbst erzeugt wurde

Erzeugen eines Objektes im ImmortalMemroy

Erzeugen eines Objektes im ScopedMemory

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

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

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 NoHeapRealtimeThreads Thread 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

Erzeugen eines einfach Realtime Threads

Ändern der eigenen Thread Priorität

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

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

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

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

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 werden Die RTSJ fordert eine FIFO für jedes Prioritätslevel

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

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

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 Ereignis AsyncEventHandler: Enthält den auszuführenden Code

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 Raumfahrt DD(X) – Militär netcentric battlefield – Militär Mackinca - Industrie

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

Seminar: Compiler-Konstruktion

Ähnliche Präsentationen

Präsentation zum Thema: "Seminar: Compiler-Konstruktion"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Seminar: Compiler-Konstruktion

Ähnliche Präsentationen

Präsentation zum Thema: "Seminar: Compiler-Konstruktion"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback