1 / 50

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-. Motormanagement.

latham
Télécharger la présentation

Seminar: Compiler-Konstruktion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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- Motormanagement Airbag-Steuerung ABS, ESP, usw.

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

  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 Specificationfor JAVA“  unabhängige Hersteller: „Real-Time Core Extensionsfor JAVA“ und „Real-Time Data Access“

  14. 3. Java´s Echtzeitfähigkeits-Entwicklung-History- Vorschläge basieren auf:  Definition von Objekten, die nicht der globalen Speicherplatzverwaltung unterliegen Darauf arbeitenden echtzeitfähigen Routinen (nicht beeinflussbar vom CarbageCollectior, mit der Möglichkeit zur Unterbrechung) Unterschiede: Garant das Echtzeitroutinen keine Heap-Objekte manipulieren Hardwarezugriff

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

  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 GarbageCollection 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.

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

  20. Größtes Problem: Unterbrechung durch GarbageCollection • 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 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement-

  21. 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement- • heap Memory: • Speicher entspricht dem Heap. Lebenszeit eines Objektes wird durch seine Sichtbarkeit begrenzt. •  traditionelle Speicherart der JavaVM

  22. 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement- • physical Memory: • Speicher wird für Objekte verwendet, die spezielle physikalische Speicherbereiche benötigen, z.B. DMA Adressbereich

  23. 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement- • 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. 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement- • 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 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement-

  26. Für neue Speicherbereiche gelten neue Regeln hinsichtlich der Referenzierungvon Objekten •  Trotz Freiheitsgrade Robustheit der Java-Spezifikation behalten • Einschränkungen beim referenzieren auf Objekte in den neuen Speichertypen zu beachten: 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement- Grundsatz Eine Variable darf zu keinem Zeitpunkt eine Referenz auf ein Objekt haben, welches von ihr selbst gelöscht werden kann.

  27. 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement- • 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. 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement- • 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

  29. Erzeugen eines Objektes im ImmortalMemroy 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement-

  30. Erzeugen eines Objektes im ScopedMemory 4. Java´s Probleme und Lösungsansätze -Lösung: Speichermanagement-

  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. 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 4. Java´s Probleme und Lösungsansätze -Lösung: Scheduling-

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

  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 • NoHeapRealtimeThreads • Thread kann nicht durch die GarbageCollection unterbrochen werden. Threadtyp ist für höchst zeitkritische Anforderungen gedacht. Damit bei Heapzugriffen keine Inkonsistenzen entstehen, darf nicht auf den Heap zugegriffen werden 4. Java´s Probleme und Lösungsansätze -Lösung: Scheduling-

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

  36. Erzeugen eines einfach Realtime Threads 4. Java´s Probleme und Lösungsansätze -Lösung: Scheduling-

  37. Ändern der eigenen Thread Priorität 4. Java´s Probleme und Lösungsansätze -Lösung: Scheduling-

  38. Ändern der eigenen Thread Priorität 4. Java´s Probleme und Lösungsansätze -Lösung: Scheduling-

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

  41. 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 -Lösung: Hardwarezugriffe-

  42. 4. Java´s Probleme und Lösungsansätze-Problem: Synchronisation- Zusammenhang: Scheduling und GarbageCollection Beruht auf blockierenden Protokollen (gegenseitiger Ausschluss)  Bei Synchronisation von zeitkritischen und zeitunkritischen Threads darf die GarbageCollection nie gestartet werden, um Verzögerungen im zeitkritischen Code zu verhindern

  43. 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 4. Java´s Probleme und Lösungsansätze-Lösung: Synchronisation-

  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 PriorityInhertiance Protocol • Zusätzlich gibt es das PriortyCeiling Protocol • Beide Verfahren heben die Priorität des sperrenden Threads an, um dessen Abarbeitung zu beschleunigen • Unterschied: Zeitpunkt 4. Java´s Probleme und Lösungsansätze-Lösung: Synchronisation-

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

  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 waitfreequeues ein •  Warteschlange mit besonderen Eigenschaften 4. Java´s Probleme und Lösungsansätze-Lösung: Synchronisation-

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

  48. 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 4. Java´s Probleme und Lösungsansätze -Asynchrone Ereignisse-

  49. Echtzeitbibliotheken im Modul javax.realtime.* gekapselt • Kommerzielle Anbietung der implementierten RTSJ: •  JamaicaVM der aicasGmBH •  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 • netcentricbattlefield – Militär • Mackinca - Industrie 5. Anwendungen

  50. 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 6. Fazit

More Related