Fehlertoleranz durch aspektorientierte Programmierung

Transkript

1 Fehlertoleranz durch aspektorientierte Programmierung Max Günther Technische Universität Dortmund 5. März / 34

2 Motivation Fehlertoleranz ist wichtig aber mühselig in Software einzubauen Abhilfe durch aspektorientierte Programmierung (AOP) Code Magie? Fehlertoleranz Binärcode 2 / 34

3 Inhalt 1 Motivation 2 Aspektorientierte Programmierung 3 OSGi 4 Fehlertoleranz in OSGi 5 Fehlertoleranz in Programmen 6 Fazit 3 / 34

4 Was ist aspektorientierte Programmierung? public void foo () { logging (" beginne foo ");... logging (" foo erfolgreich "); } public void bar () { logging (" beginne foo ");... logging (" foo erfolgreich "); } redundanter Code ist schlecht insbesondere bei querschneidenen Belangen aspektorientierte Programmierung querschneidene Belange werden separat implementiert anschließend werden sie in den Code eingewoben 4 / 34

5 AspectJ AspectJ ist Aspektorientierung für Java man definiert Pointcuts und Advices an diesen wird der spezielle Aspektcode ausgeführt der spezielle Aspektcode wird von einem Aspektweber in den Code eingewoben 5 / 34

6 AspectJ - Beispiel public aspect AspectJExample { pointcut logging () : execution ( int MyClass. check *(..)) execution ( String MyClass. check *(..)); } void before () : execution ( logging ()) && this ( foo ) { System. out. println (" Vor dem Aufruf von " + foo. tostring ()); } 6 / 34

7 Was ist OSGi? eine Plattform zum dynamischen Laden von Softwarekomponenten geschrieben in Java State of the Art (in Java) bekannte Implementierungen: Equinox (Eclipse), Apache Felix und Knopflerfish 1 1 Quellen Bilder: / 34

8 Softwarekomponenten teilen Software in kleine Teile können weitgehend unabhängig voneinander entwickelt werden bieten Services an verwenden Services können dyamisch zur Laufzeit des Programmes geladen werden und installiert, gestarted, gestoppt, deinstalliert 8 / 34

9 Probleme mit Fehlern in OSGi defekte Softwarekomponenten gefährden die Stabilität der OSGi Plattform Probleme durch übermäßigen CPU Verbrauch übermäßigen Speicherverbrauch (ungültige Referenzen) native Treiber native Bibliotheken 9 / 34

10 Fehlertoleranz in OSGi durch aspektorientierte Programmierung hier Paper Applying Dependability Aspects on Top of Aspectized Software Layers [2] Sandboxes werden verwendet um nicht vertrauenswürdige Komponenten zu isolieren Sandboxes werden durch AOP in verschiedene OSGi Implementierungen eingewoben dadurch weniger Coderedundanz sowie Wiederverwendbarkeit über mehrere Implementierungen nicht vertrauenswürdig vertrauenswürdig OSGI OSGI + 10 / 34

11 Darstellung der Layer durch AOP verschiedene Layer von OSGi sind in der API verstreut diese Layer sind also querschneidend Layer können als Aspekte definiert werden! Ausschnitt für den LifeCycle Aspekt[2]: public aspect LifeCycle { pointcut install (): execution ( Bundle BundleContext +. installbundle ( String,..)); pointcut stop (): execution ( void Bundle +. stop (..)); } pointcut deactivate (): call ( void BundleActivator +. stop ( BundleContext )); 11 / 34

12 Dependability interessant sind die Abhängigkeiten zwischen den Layern und den Komponenten hier entsteht die Anfälligkeit für Fehler vier Aspekte: Isolierung von Komponenten (Component Isolation Aspekt) Isolierung von Services (Service Isolation Aspekt) Überwachung von Services (Stale Service Monitoring Aspekt) Verwaltung (Autonomer Management Aspekt) 12 / 34

13 Component Isolation Aspekt Unterscheidung von vertrauenswürdigen und nicht vertrauenswürdigen Komponenten (durch eine Policy Datei) zwei Platformen: eine für vertrauenswürdige, eine für nicht vertrauenswürdige Komponenten beide Platformen kommunizieren über Inter Process Communication (IPC) die Komponenten Isolation schneidet sich durch die Life Cycle Transitionen und ServiceRegistry OSGI IPC OSGI + 13 / 34

14 Component Isolation Aspekt: kleines Problem einige Funktionen rufen andere Funktionen auf an beiden Funktionen wird der gleiche Code eingewoben sollte aber nur einmal eingewoben werden Lösung: cflowbelow Konstrukt (Ausschnitt[2]) public aspect ComponentIsolation { void around ( Bundle b): LifeCycle. start () &&! cflowbelow ( LifeCycle. start ()) && this (b) { if (! PlatformProxy. issandbox () && PolicyChecker. checkisolation ( b)) { PlatformProxy. start ( b. getbundleid ()); } else { proceed (); } } } 14 / 34

15 Service Isolation Aspekt Services werden innerhalb der gleichen Applikation isoliert Isolation durch Sandboxes nicht möglich stattdessen Kommunikation über Proxies Proxies: trennen Konsumenten von Anbietern (und umgekehrt) überwachen, ob nicht verwendete Referenzen entstehen (Stale References) wird eine Methode auf einem nicht (mehr) registierten Service aufgerufen Exception 15 / 34

16 Stale Service Monitoring Aspekt verwendet einen Service Coroner (Gerichtsmediziner) dieser nutzt weak references werden vom Garbage Collector nicht mitgezählt ein Objekt das nur von weak references referenziert wird, gilt als tot kann also vom Garbage Collector aus dem Speicher gelöscht werden A weak reference B A weak reference B kann aufgesammelt werden B C normale Referenz B kann nicht aufgesammelt werden 16 / 34

17 Autonomer Management Aspekt bisher: Überwachung und Isolation Autonomer Management Aspekt ergreift Maßnahmen: Analyse der Überwachungsdaten Neustarten von abgestürzten Komponenten oder der Sandbox erkannt werden[2]: übermäßge CPU Nutzung Stale Services übermäßige Speichernutzung übermäßige Thread Instanzierung übermäßiges Aufrufen von Services Aufbewahrung von Stale Services 17 / 34

18 Fehlertoleranz in Programmen durch aspektorientierte Programmierung bisher: Lösung für spezifische Plattform nun: Fehlertoleranz für allgemeinere Programme 18 / 34

19 Fault injection-based assessment of aspect-oriented implementation of fault tolerance [1] Ruben Alexanderson und Johan Karlsson haben solche Methoden getestet zwei Applikationen Fibonacci Reihe brake-by-wire Sprachen (bzw. Compiler): AspectC++ Ext (Zugriff auf globale Variablen kann gewoben werden) AspectC++ Opt optimierte Variante von AspectC++ Ext außerdem Vergleich zwischen optimiert und nicht optimiert 19 / 34

20 Double Signature Control Flow Checking (DS-CFC) Überwachung des Kontrollfluss durch Funktionskennzeichnungen Funktionen müssen die Reihenfolge beachten: Aufruf Betreten der Funktion möglichweise Aufruf von anderen Funktionen Verlassen der Funktion Rückkehr in den Kontext dazu wird ein Stack (Stapel) verwendet 20 / 34

21 Triple Time Redundant Execution mit Forward Recovery (TTR-FR) dreifache Ausführung anschließende Abstimmung über das Ergebnis gewonnenes Ergebnis wird verwendet 21 / 34

22 Testapplikationen Fibonacci Applikation berechnet Fibonacci Reihe sehr klein Fehler pflanzen sich nach spätestens zwei Iterationen fort brake-by-wire Applikation von Volvo entwickelt größer (445 Programmzeilen) näher an der Echten Welt ausgeführt auf einem MPC565 Mikrocontroller Tests mit AspectC++ Ext (mit -finline) AspectC++ Opt reine C Implementierung jeweils mit den GCC Optimierungsstufen -O0 und -O3 22 / 34

23 Fehler Modell und Injektion nur Injektion von einfachen Bitfehlern keine Injektion in das PC Register Fehlerklassen: No Effect (NE) Corrected SW (CSW) Detected SW (DSW) Detected HW (DHW) Timeout (TO) Value Failure (VF) Abdeckung X = #X N Abdeckung Gesamt = 1 #V F N 23 / 34

24 Resultat ohne Software Schutz Abdeckung NE DHW TO Gesamt Keine (geringe) Optimierungen Fibonacci 11, 7% 60, 4% 1, 4% 73, 5% Brake-by-wire 33, 3% 46, 4% 0, 4% 80, 01% Hohe Optimierung Fibonacci 3, 4% 36, 4% 0, 1% 39, 7% Brake-by-wire 36, 4% 43, 3% 0, 0% 79, 8% kleiner Anteil an NE Fehlern bei Fibonacci Effekt wird durch Optimierungen verstärkt 24 / 34

25 Resultat mit DS-CFC Schutz Abdeckung NE DSW DHW TO Gesamt Fibonacci C 13, 0% 33, 0% 48, 5% 0, 8% 95, 3% AspectC++ Ext 13, 0% 27, 9% 49, 2% 0, 8% 90, 9% AspectC++ Opt 10, 8% 35, 9% 47, 4% 0, 7% 94, 8% Brake-by-wire C 24, 7% 17, 0% 46, 8% 0, 4% 88, 9% AspectC++ Ext 26, 1% 20, 7% 44, 5% 0, 2% 91, 5% AspectC++ Opt 26, 4% 22, 2% 41, 1% 0, 5% 90, 2% Verbesserung - 17% bis 36% hohe Gesamtabdeckung 25 / 34

26 Resultat mit TTR-FR Schutz Abdeckung NE CSW DSW DHW TO Gesamt Fibonacci C 12, 3% 33, 4% 0, 5% 49, 0% 1, 3% 96, 4% AspectC++ Ext 15, 8% 27, 2% 0, 2% 55, 0% 0, 3% 98, 5% AspectC++ Opt 13, 6% 32, 6% 0, 4% 50, 3% 1, 0% 97, 8% Brake-by-wire C 34, 5% 15, 2% 0, 9% 45, 6% 0, 2% 96, 4% AspectC++ Ext 26, 3% 12, 0% 0, 8% 56, 3% 0, 1% 95, 5% AspectC++ Opt 33, 2% 17, 1% 0, 5% 45, 3% 0, 3% 96, 5% nöch höhrere Gesamtabdeckung CSW + DSW entspricht der DSW von DS-CFC 26 / 34

27 Overhead TTR-FR mit wenigen Optimierungen (in %) 1,000 1, code data trace C AspectC++ Ext AspectC++ Opt 27 / 34

28 Overhead TTR-FR mit hohen Optimierung (in %) code data trace C AspectC++ Ext AspectC++ Opt 28 / 34

29 Overhead DS-CFC mit wenigen Optimierungen (in %) code data trace C AspectC++ Ext AspectC++ Opt 29 / 34

30 Overhead DS-CFC mit hoher Optimierung (in %) code data trace C AspectC++ Ext AspectC++ Opt 30 / 34

31 Fazit AOP verringert den Aufwand für den Programmierer AOP führt neue Modularität in Programmcode ein insbesondere vorteilhaft für objektorientiere Architekturen die Schichten verwenden lesbarer, flexibler und portablerer Code Overhead bei Ausführung, Codegröße und Datengröße Overhead ist akzeptabel wenn Optimierungen verwendet werden 31 / 34

32 Quellen I Ruben Alexandersson, Johan Karlsson, Fault injection-based assessment of aspect-oriented implementation of fault tolerance. Dependable Systems and Networks (DSN), , IEEE Computer Society Washington, DC, USA, Kiev Gama, Didier Donsez, Applying dependability aspects on top of aspectized software layers. Proceedings of the tenth international conference on Aspect-oriented software development (AOSD), , ACM, the OSGi Alliance, The OSGi Architecture. Oliver Böhm, Aspektorientierte Programmierung mit AspectJ 5. dpunkt.verlag, 2005.

33 Quellen II the AspectJ Team, The AspectJ(tm) 5 Development Kit Developer s Notebook.

34 Vielen Dank für Ihre Aufmerksamkeit