J-Orchestra. Motivation. Automatic Java Application Partitioning. Application Partitioning

Transkript

1 J-Orchestra Automatic Java Application Partitioning Motivation Application Partitioning Bezeichnet das Aufteilen einer Applikation in unabhängige Teile, die unter Erhaltung der Gesamtfunktionalität in einer verteilten Umgebung laufen können. Dient vor allem der Nutzung von verteilten Daten und verteilter Rechenleistung sowie der Integration zusätzlicher Hardware. 1

2 Ansätze Konventionelle Ansätze Partitionierung durch manuelle Modifikation der Anwendung auf Quellcodeniveau Anschließende Integration der Applikationsteile durch Middleware Shared Memory Systeme: Modifikation der JVM Pangaea an der FU Berlin von André Spiegel entwickelt automatische Front-End Distribution für Java frei Wahl der Middleware Modifikation auf Quellcode-Niveau Ansätze J-Orchestra Automatisierte Partitionierung bestehender Programme mittels byte code rewriting RMI als Middleware Keine Modifikation des Quellcodes Keine Modifikation der JVM Unterstützung von Objektmigration GUI-Unterstützung bei der Partionierung 2

3 Strategie Überblick über die generelle Vorgehensweise von J-Orchestra beim Partitionieren von Applikationen Strategie Allgemein: Ortstransparenz herstellen mittels automatischer Ersetzung lokaler Zugriffe durch Proxyzugriffe generiert werden Proxy-Klassen Remote-Klassen Infrastruktur ObjectFactory für Remote-Erzeugung RMI als Middleware 3

4 Nativer Code Systemklassen greifen auf nativen Code zurück, dieser nicht migriert werden Verteilung ist also nicht immer möglich Partitionierung muss diese Einschränkung berücksichtigen Anhand dieses Kriteriums kann eine Codeklassifikation vorgenommen werden Codeklassifikation Mobile Classes Objekte können prinzipiell migrieren verschiedene Migrationsverfahren möglich typischerweise ist Applikationscode mobile Anchored Classes Kriterien: Klasse besitzt native Methoden oder Klasse leitet eine anchored Klasse ab (Ausnahme java.lang.object) oder Objekte dieser Klasse werden von anderen anchored Klassen verwendet Objekte können nicht migrieren Häufig in Java-Systemklassen 4

5 Codeklassifikation (Un)modifiable Code Code kann (nicht) verändert werden z.b. Java-Systemklassen, Lizenzgründe usw. Mögliche Fälle: Client: unmodifiable, Server: modifiable replace approach: Proxyklasse einführen mit dem Namen der Originalklasse Originalklasse umbenennen Unmodifiable Code Client: modifiable, Server: unmodifiable Referenzen beim Client auf eine Proxyklasse mit neuem Namen umleiten direkte Zugriffe auf Objektvariablen des Servers müssen durch Methodenaufrufe ersetzt werden all-or-none Semantik Client: unmodifiable, Server: unmodifiable keine Partitionierung möglich Client und Server müssen in der selben JVM laufen (co-anchored) 5

6 Codeklassifikation Architektur Vorstellung der Aufgaben und Funktionsweisen der J-Orchestra -Systemkomponenten 6

7 Systemarchitektur Profiler: statische Codeanalyse Definition der Partitionierung und der Migrationsrichtlinien durch den Benutzer Classifier: Codeklassifizierung Sicherung d. Korrektheit Translator: byte code rewriting Erzeugung von Java- Code zur Fehlerbehandlung Profiler statische Analyse des Programms gruppiert Klassen anhand ihrer Abhängigkeitsstruktur und ihrer Funktion (Graphik, Sound, Dateisystem etc.) (Heuristik) führt Testläufe zur Optimierung durch unterstützt den Nutzer bei der Erstellung einer sinnvollen Partitionierung, der Platzierung von Klassen und der Erstellung von Migrationsrichtlinien 7

8 Classifier führt die Klassifizierung (mobile oder anchored) des vorhanden Codes durch stellt fest, welche Klassen zusammen platziert werden müssen (co-anchored). stellt die Korrektheit der gewählten Objektplatzierung und Migrationsrichtlinien fest Rewriting Erläuterung des Vorgehens bei der automatischen Modifikation des Bytecodes von Java Applikationen 8

9 Mobile & Modifiable A interface interface interface A interface A interface extends extends Remote{ Remote{ void void foo() foo() throws throws RemoteException; RemoteException; A class A { void foo(){ Mobile & Modifiable A A interface class class A A implements implements java.io.externalizable{ java.io.externalizable{ A interface A interface ref; ref; void void foo(){ foo(){ try A try {ref.foo {ref.foo catch catch (RemoteException (RemoteException e){ e){ // // let let user user provide provide handling handling class A { void foo(){ 9

10 Mobile & Modifiable A A interface A remote A class class A remote A remote extends extends UnicastRemoteObject class UnicastRemoteObject A { implements implements A interface{ A interface{ void void foo(){ void foo() foo() throws throws RemoteException{ RemoteException{ Mobile & Modifiable A interface A remote A interface A A 10

11 Mobile & Modifiable A interface A remote A interface A A Anchored & Unmodifiable 11

12 Anchored & Unmodifiable C interface remotecapable.c C translator package package remotecapable; remotecapable; class C class C translator C translator extends extends UnicastRemoteObject UnicastRemoteObject implements implements C interface{ C interface{ C C originalclass; originalclass; void void foo(remotecapable.p foo(remotecapable.p p) p) throws throws RemoteException{ RemoteException{ originalclass((p)runtime.unwrap(p)) originalclass((p)runtime.unwrap(p)) class C { void foo(p p){ remotecapable.p remotecapable.p bar() bar() throws throws P bar() RemoteException{ RemoteException{ { return return (remotecapable.p) (remotecapable.p) Runtime.wrap( Runtime.wrap( originalclass.bar()); originalclass.bar()); Anchored & Unmodifiable C interface remotecapable.c C interface remotecapable.c P interface C translator P translator C remotecapable.p P 12

13 Anchored & Modifiable Anchored Modifiable Classes Werden wie anchored unmodifiable classes gehandhabt können jedoch so modifiziert werden, das evtl. existierende Zugriffe auf Felder anderer Klassen durch Methoden ersetzt werden dadurch müssen diese anderen Klassen nicht mehr zwangläufig anchored sein. 13

14 Java Language Features Beschreibt den Umgang mit Besonderheiten der Java-Spezifikation bei der Partitionierung Statische Zugriffe Zugriff auf statische Felder werden durch entsprechende Methoden ersetzt Es werden statische Delegatorklassen generiert, die für das ExceptionHandling zuständig sind. //Original class class A { static void foo (String s) {... static int bar () {... //Static Delegator for A--runs on a remote site class A StaticDelegator extends java.rmi.server.unicastremoteobject { void foo (String s) { A remote.foo (s); int bar () { return A remote.bar (); 14

15 Objekterzeugung Neue Objekte werden von den Proxies nicht lokal erzeugt Konstruktoraufrufe am Proxy bewirken nichts An jedem Netzort existiert eine ObjectFactory, die sich untereinander kennen Jede Factory wird durch J-Orchestra konfiguriert Objekte werden ggf. an einem anderen Ort erzeugt und eine entsprechende Remote- Referenz geholt. this-referenzen //original code class A { void foo (B b) { b.baz (this); class B { void baz (A a) {... //generated remote object for A class A remote { void foo (B b) { b.baz (this); // this is of type A remote! Änderung im Bytecode: aload_0 //pass this to locateproxy method invokestatic Runtime.locateProxy checkcast A //locateproxy returns Object, need a cast to A astore_2 //store the located proxy object for future use aload_1 //load b aload_2 //load 15

16 Multithreading RMI unterstützt nicht die Transparenz von Synchronisationsmechnismen wie synchronized(remoteobject){ remoteobject.wait() oder remoteobject.notify() Umsetzung nicht trivial (z.b. Deadlocks bei Übertragung des Kontrollflusses über das Netzwerk) synchronized: nur im RemoteObject, nicht im Proxy Die final Methoden wait/notify/notifyall werden durch eigenen Methoden ersetzt und an das RemoteObject übertragen Reflection Funktioniert häufig im Normalfall (Methoden) Jedoch nicht immer Idee: Umleitung an ein eigenes Reflection-API bis jetzt nicht realisiert Dynamisches Klassenladen wird nicht unterstützt Idee: eigenen J-Orchestra Classloader verwenden 16

17 Garbage Collection keine keine eigene Anpassung Verwendet wird die RMI-Unterstützung: Remote Reference Counting jedoch: über das Netz verteilte Zyklen werden nicht abgeräumt Innere Klassen Für innere Klassen werden vom Compiler für den Zugriff auf private Methoden und Felder synthetic Methoden erzeugt. Problem: Proxies werden in Sourceform erzeugt, synthetic Methoden können nicht kompiliert werden synthetic Methoden werden in sichtbare Methoden umgewandelt 17

18 In der Praxis Performance und realer Einsatz von J-Orchestra Performance Indirektionen erzeugen Overhead Abhilfe durch anchoring per choice direkte Zugriffe bleiben erhalten wichtigstes Partitionierungskriterium Zahl mobiler Objekte minimieren 18

19 Performance Umschreiben von J-Orchestra durch J-Orchestra brachte eine Verlangsamung von 37 Prozent anchoring by choice Klassen mit ähnlicher Funktionalität bleiben für die gesamte Ausführungszeit gemeinsam in der selben JVM Zugriffe untereinander erfolgen direkt Zugriffe von außen selten im Verhältnis zu internen Zugriffen oft analog zur Packagestruktur bspw. Grafik-, Sound, IO- Funktionalität reduziert den overhead gegen 0 Performance A interface A A remote A interface A lazy remote object creation lokal werden vom Proxy zunächst lazy-objekte erzeugt dieses ist nicht von UnicastRemoteObject abgeleitet erst beim ersten Zugriff im Remote-Kontext wird dieses Objekt durch die Remote- Implementierung ersetzt geringerer overhead, da Konstruktor von UnicastRemoteObjekt sehr komplex 19

20 JBits kommerzielle industrielle Application in Bytecode-Form (FPGA Simulator) 1920 Klassen, 7,5 MB Ziel: GUI auf einen anderen Rechner exportieren Ergebnis: ca Klassen anchored by choice auf dem Server (rechenintensive Simulation) 259 Klassen anchored auf dem Client (GUI), davon 144 aus JBits (der Rest AWT, Swing) Rest: anchored auf dem Server JBits Dauer für das Erstellen der besten Partitionierung: 1-2 Tage Optimierung: Zahl der Remote-Zugriffe durch mobile Objekte reduzieren (Benutzer) Vergleich mit Zugriff per X-Windows: viele GUI-Operationen (Menüs, Views, Resizing, Scrolling usw.) sind ausschließlich lokal und verursachen keinen Netztransfer (wie X-Windows) Bei der Durchführung Simulation wurden weniger Daten übertragen als bei X-Windows Gesamtperformance besser als bei X-Windows leider keine Benchmarks 20

21 Resümee J-Orchestra Partitionierung von Programmen in Bytecode-Form möglich Partitionierung schnell zu erreichen skaliert gut akzeptable bis gute Performance bei optimaler Partitionierung GUI-Unterstützung optimale Partitionierung nicht trivial Systemklassen nicht mobil (problematisch vor allem bei java.util.*) nützlich nur bei grobkörniger Partitionierung wie Trennung zw. GUI, Applikationslogik, Persistenzschicht leider ungeeignet für verteiltes Rechnen (Vektoren, Arrays) 21

22 Vielen Dank Fragen 22