Folien zur Java Plattform - Professur für Mikrorechner - Technische ...

Farbverlauf 

Eingebettete Systeme 

Java in eingebetteten 

Systemen 

◆ JavaPlattform 

◆ ClassFiles 

Christian Hochberger 

Professur Mikrorechner 

Fakultät Informatik 

Technische Universität Dresden

Die Java Plattform 

Chr. Hochberger, Fakultät Informatik, TU Dresden 2

Architektur der VM 


Struktur des ClassFiles 


Einträge im ConstantPool 


Einträge im ConstantPool (2) 


Constant Pool – Beispiel 


Fields und Methods 

•Field Attribute: 

ConstantValue 

Synthetic 

•Method Attribute: 

Code 

Exceptions 

Synthetic 


Code Attribut 


Descriptor 

Field Descriptor: Field Type 

Method Descriptor: ( Field Type * ) Return Type 

Field Type: Base Type | Object Type | Array Type 

Object Type: Lclassname; 

Array Type: [ Field Type 

Base Type: B|C|D|F|I|J|S|Z 

Return Type: Field Type | V 

Beispiel: 

(JI)V ⇒ void wait(long timeout, int nanos) 

(ZIJLjava/lang/String;)Z ⇒ 

boolean dummy(boolean a,int b,long c, String d) 


Class Loader 

Aufgaben: 

Laden: Lokalisieren und Importieren der Binärdaten einer 

Klasse 

Linken: 

Verifikation: Überprüfen der Korrektheit 

Vorbereitung: Allokation von Speicher für statische 

Felder 

Resolution: Transformation von symbolischen in 

direkte Referenzen 

Initialisierung: Ausführung des Codes zur Initialisierung 

der statischen Felder 


Class Verifier 

Formatüberprüfung des ClassFiles 

Überprüfung aller Constant Pool Einträge 

z.B. getstatic: Eintrag muss vom Typ 

CONSTANT_Fieldref sein 

Überprüfung symbolischer Referenzen 

(Superklassen, referenzierte Klassen) 

Typprüfungen (final, abstract, Methodeninferenz) 

Überprüfung von Sprungadressen 

Datenflussanalyse, um Typkorrektheit zu prüfen 


ResolutionTypen 

Auflösen symbolischer Referenzen und Ersetzen durch direkte 

Referenzen: 

Unterscheidung von early resolution und late resolution 

ClassResolution 

Laden der entsprechenden Klasse (und Superklassen) 

MethodResolution: 

Suchen einer Methode mit passendem Namen 

Typinferenz ⇒ Stringmatching der Descriptors 

Prüfen der Zugriffsrechte 

FieldResolution: 

Suchen eines Fields mit passendem Namen 

Typprüfung 

Prüfen der Zugriffsrechte 


Interne Repräsentation von Klassen 


Datentypen der JVM 

Datentypen 

Numerische 

Typen 

Referenzen 

Fließkomma 

Integral 

Objekt 

Array 

float 

double 

byte 

char 

short 

Chr. Hochberger, Fakultät Informatik, TU Dresden 15 

int 

long

Objekt Referenzen (Handle) 

Zweistufiges Verfahren, Objektreferenz ⇒ Handle ⇒ 

Instanz 

Zusätzlicher Speicherplatz erforderlich 

Kompaktieren des Speichers einfacher 


Objekt Referenzen (Direkter Zeiger) 

Einstufiges Verfahren, Objektreferenz ⇒ Instanz 

Zugriff auf Objektdaten schneller 

Kompaktieren des Speichers sehr schwer 


Java Frames 

Beim Aufruf jeder JavaMethode wird ein StackFrame erzeugt: 

Lokale Variablen: 

WortArray fester Größe 

Die ersten N Einträge sind die Parameter der Methode 

Instanzmethoden erhalten Objektreferenz als ersten 

Parameter 

Operanden Stack: 

Dient zur Aufnahme der Zwischenergebnisse 

VM hat keine Register (außer PC) 

Frame Daten: 

Zeiger auf ausgeführte Methode 

Zeiger auf Constant Pool der Klasse 

Zeiger auf Exception Tabelle 


Lokaler Stack 


Globaler Stack 


Bytecode Struktur 

Alle Befehle bestehen aus einem Byte 

Für jede Methode einer Klasse wird ein ByteArray 

mit allen Befehlen gespeichert 

Argumente (meistens 1 oder 2 Byte) folgen im 

Bytestrom 

Argumente sind 

Konstanten 

Indizes in den Konstantenpool 

Komplexe Datenstrukturen (lookupswitch) 


Bytecode Gruppen 

Stack Operationen 

Typkonversionen 

Logische und Arithmetische Operationen 

ObjektHandling 

Flusskontrolle 


Bytecode:Stack Operationen 

Ablegen von Konstanten auf dem Stack (iconst_[-1..5], 

fconst_[0..2],lconst_[0,1], dconst_[0,1], 

aconst_null) 

Ablegen von Immediate Werten auf dem Stack (bipush byte1, 

sipush byte1, byte2) 

Ablegen von Konstanten aus dem Konstantenpool auf dem Stack 

(ldc ibyte1, ldc_w ibyte1,ibyte2, ldc2_w ibyte1,ibyte2) 

StackManipulationen (pop, pop2, dup, dup2, swap, dup_x1, ...) 

Laden und Speichern von lokalen Variablen ([i,f,l,d,a]load 

ibyte1, [i,f,l,d,a]load_[0..3], [i,f,l,d,a]store 

ibyte1, ...) 

wide Präfix macht aus 8Bit Index 16Bit Index 


Bytecode: Beispiel 


Bytecode: Typkonversionen 

Umwandlung verschiedener primitiver Datentypen 

ineinander: 

Quelle int: i2l, i2f, i2d, i2b, i2s, i2c 

i2b und i2s schneiden obere Bytes ab und führen 

SignExtension durch. i2c schneidet ab und füllt den 

oberen Teil mit Nullen 

Quelle long: l2i, l2f, l2d 

Quelle float: f2i, f2l, f2d 

Quelle double: d2i, d2l, d2f 


Bytecode: Logische und 

Arithmetische Operationen 

int: 32 Bit Zweierkomplement, 

long: 64 Bit Zweierkomplement 

Floating Point: IEEE 754 

float: 1 Bit Vorzeichen, 8 Bit Exponent, 23 Bit Mantisse 

double: 1 Bit Vorzeichen, 11 Bit Exponent, 52 Bit 

Mantisse 

Binäre Operationen ([i,l,f,d][add,sub,mul,div,rem]) 

Unäre Operationen ([i,l,f,d]neg, iinc ibyte1,const, 

wide iinc ibyte1,ibyte2,const1,const2) 

logische Operationen ([i,l][shl,shr,ushr,and,or,xor]) 


Bytecodes: ObjektHandling 

Erzeugen eines Objektes: new ibyte1,ibyte2 

Lesen/Schreiben von Objektfeldern: [get,put]field 

ibyte1,ibyte2 

Lesen/Schreiben von statischen Objektfeldern: 

[get,put]static ibyte1, ibyte2 

Sicheres Typecasting: checkcast ibyte1,ibyte2 

Überprüfen des Objekttyps: instanceof ibyte1,ibyte2 

Anlegen von Feldern: newarray atype, anewarray 

ibyte1,ibyte2, multianewarray ibyte1,ibyte2,dim 

Feststellen der aktuellen Arraygröße: arraylength 

Lesen/Schreiben von ArrayElementen: 

[b,c,s,i,l,f,d,a][aload,astore] 


Bytecodes: Flusskontrolle 

Alle Sprungdistanzen in Zweierkomplementdarstellung, Addition 

des Offsets zur Adresse des Opcodes 

Bedingte Sprünge 

Bedingung vom Stack: if[eq,ne,lt,le,gt,ge] 

obyte1,obyte2 

Vergleich zweier Werte: 

if_icmp[eq,ne,lt,le,gt,ge] obyte1,obyte2 

Vergleiche von long, float und double: lcmp, [f,d]cmp[g,l] 

Vergleiche von Objektreferenzen: if[non]null, 

if_acmp[eq,ne] 

Unbedingter Sprung: goto obyte1,obyte2, 

goto_w obyte1,obyte2,obyte3,obyte4 

Tabellensprünge: tableswitch, lookupswitch 


tableswitch 

Komplexe Datenstruktur nach dem Bytecode 

DefaultWert 

Erster Index in Tabelle, Letzter Index in Tabelle 

Tabelle mit Sprungdistanzen 

Konstante Ausführungszeit 

Padding 

Allignment der 32 Bit Werte 

Adr % 2 2 == 0 

Indextabelle 

Erlaubt direkten Zugriff durch CPU 

opc pad0 ... padn 

Default 

Min. Index 

Max. Index 


...

lookupswitch 

Komplexe Datenstruktur nach dem Bytecode 

DefaultWert 

Anzahl WertOffset Paare 

Tabelle mit Paaren (Wert, Offset) 

Ausführungszeit unbekannt! 

WertOffsetTabelle 

opc pad0 ... padn 

Default 

NPairs 

Value Offset 


...

Bytecode Ausführung (Beispiel) 

Beispiele auf http://www.artima.com/insidejvm/applets/ 

public class demo extends Object { 

void jumpAround(int a,int b) { 

int i; 

} 

} 

for (i=0; i

Exceptions 

Können durch Fehler bei der Abarbeitung entstehen 

Arithmetische Fehler (Division durch 0) 

Nullpointer Referenzierung 

Fehler beim Laden von Klassen 

Fehler beim IO 

Können explizit durch Programm erzeugt werden: 

athrow: Objektreferenz auf dem Stack wird als 

Exception geworfen 

Objekt muss Ableitung von Throwable sein 


Exceptions im ClassFile 

Start PC, End PC 

Bytecode Bereich (End PC1!), der durch diesen tryBlock 

abgedeckt wird 

Handler PC 

Bytecode Offset, an dem der entsprechende Handler 

(catchBlock) beginnt 

Exception Type 

Constant Pool Index, der die ExceptionKlasse beschreibt, die 

abgefangen wird 

Exception Type == 0 (illegaler Constant Pool Index) 

⇒ Implementierung der finally Klauseln 


Exception Processing 

Vorgehensweise beim Auftreten einer Exception: 

Durchsuchen der aktuellen Exception Table 

Aktueller PC liegt in einem Bereich: 

Entspricht Exception Type der aktuellen Exception? 

Ja ⇒ Handler ausführen 

Nein ⇒ Superklasse der aktuellen Exception mit Exception 

Type vergleichen 

Schritt wiederholen, bis Throwable erreicht ist 

Keinen passenden Handler gefunden? 

Aktuellen Stack Frame löschen 

Im übergeordneten Stack Frame Suche wiederholen 


Method Invocation 

invokestatic ibyte1,ibyte2: 

Neuen Stack Frame erzeugen, 

Argumente als lokale Variablen auf neuen Stack legen, 

Klassenmethode gemäß Constant Pool Eintrag aufrufen 

Resolution kann feste Adresse der Methode eintragen 

invokevirtual ibyte1,ibyte2: 

Neuen Stack Frame erzeugen, 

Objektreferenz als Argument 0 ablegen, 

Argumente als lokale Variablen auf neuen Stack legen, 

Instanzmethode gemäß Objektreferenz aufrufen 

Resolution kann Index in Methodentabelle des Objekttyps 

eintragen 


Method Invocation (2) 

invokeinterface ibyte1,ibyte2,nargs,0: ähnlich wie 

invokevirtual, aber andere Optimierung durch Resolution 

nötig 

invokespecial ibyte1,ibyte2 

Mischung aus invokestatic und invokevirtual: 

Klassenmethode aufrufen, aber Objektreferenz übergeben 

(statische Bindung) 

Konstruktoren 

Ausführen von privaten Methoden in Superklassen 

Ausführen von überschriebenen Methoden aus 

Superklassen 


Method Invocation (3) 

Native Methoden: Bleiben dem VM Implementierer überlassen 

Beenden von Methoden: 

return: Ohne Rückgabewert zurückkehren 

[i,l,f,d,a]return: Entsprechenden Wert vom Stack 

lesen und auf aufrufendem Stack ablegen 


MethodenTabellen 

public class A extends Object { 

private int P1 (); 

public void O1 (); 


} 

public class B extends A { 



} 

public class C extends A { 




} 


Synchronisation 

Monitorbasierte Synchronisation durch Bytecodes: 

monitorenter: Referenz vom Stack nehmen und Objekt 

blockieren 

Objekt bereits von anderem Thread blockiert: 

Diesen Thread suspendieren 

Objekt von diesem Thread oder noch nicht blockiert: 

Zähler erhöhen 

monitorexit: Referenz vom Stack nehmen und Zähler 

erniedrigen 

Zähler > 0: Thread läuft normal weiter 

Zähler = 0: Prüfen, ob anderer Thread wartet, evtl. neu 

schedulen 


SynchronisationBeispiel 

public class Sync extends Object { 

public void a(Object b) { 

int c; 

synchronized (b) { 

c=1; 

} 

} 

} 

0 aload_1 

1 astore_3 

2 aload_3 

3 monitorenter 

4 iconst_1 

5 istore_2 

6 aload_3 

7 monitorexit 

8 return 

9 aload_3 

10 monitorexit 

11 athrow 

Exception table: 

from to target type 

4 6 9 any 


synchronized Methoden 

Bei synchronized Methoden muss VM Monitor belegen 

und freigeben: 

Bei Instanzmethoden wird this benutzt 

Bei statischen Methoden wird ClassObjekt benutzt 

public class Sync2 extends Object { 

public synchronized void a(Object b) { 

int c; 

c=1; 

} 

} 

0 iconst_1 

1 istore_2 

2 return 


Wait Sets und Object 

Keine Bytecodes für Methoden wait(), notify() und 

notifyAll(): 

wait() trägt aktuellen Thread in Wait Set des Objektes ein 

notify() nimmt einen Thread aus Wait Set des Objektes 

heraus 

notifyAll() nimmt alle Threads aus dem Wait Set des 

Objektes heraus 

Implementierung des Wait Sets nicht vorgegeben: 

bei notify() muss nicht höchst priorisierter Thread 

gewählt werden 

bei notify() muss nicht ältester Thread gewählt werden 


Thread Behandlung 

Keine Bytecodes für Erzeugen, Beenden oder Manipulieren von 

Threads: 

Eintrag in die ThreadVerwaltung der VM durch 

Konstruktor (muss dann native Methode sein) 

oder Methode start() (muss in jedem Fall nativ sein) 

Methoden zur Manipulation von Threads müssen nativ sein 

(sleep(), setPriority(), join(), interrupt(), 

yield()) 

Scheduling im Ermessen des Implementierers: 

TimeSlicing ? 

Strikte Prioritätensteuerung ? 


Spezielle Bytecodes 

impdep[1,2]: implementationsspezifische Verwendung 

darf nicht in ClassFiles auftauchen 

Kann z.B. benutzt werden, um Resolution nativer 

Methoden zu implementieren 

breakpoint: Soll für Debugger benutzt werden 

jsr obyte1, obyte2: Aufruf von Unterprogrammen, 

Rücksprungadresse wird auf dem Stack abgelegt 

ret index: Rückkehr vom Unterprogramm, 

Adresse kommt aus lokaler Variable 

Unterprogramm speichert Rücksprungadresse in 

lokaler Variable 


Resolution 

Drei Fälle unterscheidbar 

ClassRef (new, instanceof, checkcast, ...) 

CPIndex wird ersetzt durch Index in Klassentabelle 

FieldRef ([get,put]static, [get,put]field) 

Field: 

➢ CPIndex wird ersetzt durch Offset im Objekt 

➢ Probleme, wenn Objekt mehr als 65536 Felder enthält 

Static: 

➢ CPIndex wird zu Index in StaticTabelle 

(je Klasse oder global) 

Method/InterfaceRef (invokeXXX) 


Invokevirtual 

CPIndex beschreibt MethodRef 

Klasseninformation muss aus Objekt 

bezogen werden! 

Problem: Wieviel Argumente liegen 

auf Stack? 

Eigentlich erst bekannt, wenn man 

die Methode kennt. 

Lösung: Resolution trägt zwei Werte hinter 

invokevirtual_quick ein: 

Index in Methodentabelle (Klasse kommt ja aus Objekt) 

Anzahl der Argument auf dem Stack 

Stack 

this 

arg1 

arg2 

argn 


unbekannt

Invokeinterface 

Index der InterfaceMethoden kann in jeder Klasse 

anders sein 

Lösung: 

Für jedes implementierte Interface wird eine 

Methodentabelle angelegt (in jeder Klasse) 

Methodentabelle enthält Methoden dieser Klasse 

Resolution trägt dann ein: 

➢ Auswahl der Tabelle 

➢ Index in Tabelle 

➢ Anzahl der Argumente auf dem Stack 

Nur unwesentlich langsamer als Invokevirtual 


Farbverlauf 

Eingebettete Systeme 

Java in eingebetteten 

Systemen 

Implementierung der JVM 

◆ Varianten der BytecodeAusführung 

◆ Native Routinen 

◆ IOBehandlung 

◆ ThreadModelle 

Christian Hochberger 

Professur Mikrorechner 

Fakultät Informatik 

Technische Universität Dresden

Ausführung des Bytecodes 

Interpretation 

Compilation 

AheadofTime Compilation 

JustinTime Compilation 

HostspotCompilation 

Hybride Ansätze 

Alternativer Zwischencode 

Hardware Implementierung 

Mikroprogrammierte Varianten 

HardwareJIT 

BefehlssatzErweiterungen 


Interpretation 

Analyse der auszuführenden Bytecodes zur Laufzeit 

Aufruf entsprechender Programmstücke für jeden 

Befehl 

Eigenschaften: 

Einfachste Implementierung 

Kleinste Implementierung 

Langsamste Implementierung 

➢ Immer wieder Analyse der Befehle 

➢ Stack wird auf Speicherstück abgebildet 

⇒ sehr viele Speicherzugriffe 


InterpretationGrundstruktur 

Endlosschleife: 

Lesen des Bytecodes 

(dabei Weiterschalten des PC) 

Mehrfachverzweigung über Befehl 

evtl. Einlesen der Parameter 

(dabei Weiterschalten des PC) 

Ausführung des Befehls 

Verlassen der Schleife bei 

Ende der Methode ([x]return) 

Unterbrechung durch andere Threads 

blockierenden Operationen 


Intepretation Wichtige Daten 

Zeiger auf Code (PC) 

Zeiger auf Top of Stack 

Zeiger auf Beginn der lokalen Variablen 

(Zeiger auf aktuellen Frame) 

Für Zugriffe auf ExceptionTabelle 

Für Methodenaufrufe 

(Zeiger auf aktuellen Thread) 

Bei Unterbrechung durch andere Threads oder 

blockierenden Operationen 

Abbildung möglichst auf Prozessorregister 

(daher typischerweise in lokalen Variablen) 


Interpretation Verbessert 

Benutzung des "Computed Goto": 

Tabelle mit Sprungmarken für jeden Bytecode 

Am Ende der Interpretation jedes Befehls: 

➢ Laden des nächsten Befehls 

➢ direkter Sprung zum nächsten Programmstück 

Vorteil: 

➢ Vermeidung der Schleife 

➢ (Vermeidung der Bereichsprüfung bei switch 

Anweisung) 

Nachteile: 

➢ Kein ANSIC !!! 

➢ Größerer Speicherplatzbedarf 


Compilation 

Aufgaben: 

Abbildung des Bytecodes auf native 

Prozessorinstruktionen 

Abbildung der Stackmaschine auf eine 

Registermaschine (meistens) 

Probleme: 

Abbildung hochgradig prozessorspezifisch 

Anzahl der Register 

Erhalt der Echtzeitfähigkeit 


Compilation Stacktiefe 

Verteilung der Stacktiefen im Kertasarie API 

100 

90 

80 

70 

60 

50 

40 

30 

20 

10 

0 

0 1 2 3 4 5 6 7 8 9 10 12 14 16 18 20 22 

Summierte Häufigkeit 

in % 

Häufigkeit in % 


AheadOfTime Compilation 

Zwei Varianten: 

Java ⇒ Nativer Code 

Bytecode ⇒ Nativer Code 

Vorteile: 

Beliebig viel Zeit für Optimierung 

Kein Compiler im System erforderlich 

Nachteile: 

Hoher Aufwand für Typintrospektion 

Hoher Speicherplatzverbrauch 

Kein dynamisches Nachladen von Klassen 

Lösungen: 

➢ Classloader mit Compiler 

➢ Zusätzlicher Interpreter für nachgeladene Klassen 


JustInTime Compilation 

Compilation der Methoden, wenn sie gebraucht 

werden (JustInTime) 

Vorteile: 

Nur benötigte Methoden werden compiliert 

Nachteile: 

Compiler muss im System sein 

Hoher Portierungsaufwand 

Hohe StartupVerzögerung 

Hoher Speicherplatzverbrauch (Klassen + Compiler) 


Hotspot Compilation 

Compilation von Methodenfragmenten bei 

mehrfacher Nutzung 

Vorteile: 

Extrem hohe Optimierung möglich 

(da Codefragmente kurz) 

Geringerer Speicherbedarf (Klassen) als bei JIT 

Nicht so hohe StartupVerzögerung 

Nachteile: 

Sehr viel Speicherplatz für Compiler 

Komplizierte VM Konstruktion 


Registermaschine 

Hauptursache langsamer Interpretation: 

Häufige Speicherzugriffe 

Genauere Analyse: 

➢ CodeZugriffe landen im Cache 

➢ StackZugriffe passen nicht in Cache 

Idee: Abbildung des Stack auf Register 

Gewinn: 

Speicherzugriffe auf Stack werden vermieden 

Ca. 30% weniger Instruktionen (StackHandling) 

Problem: Nur machbar, wenn genügend Register 

vorhanden 


Hybride Ansätze 

Implementation zweier Interpreter in einer JVM 

RegisterCode Interpreter 

Normaler BytecodeInterpreter für 

➢ wenig benutzten Code 

➢ Code der nicht transformiert werden kann 

(Registerbeschränkungen) 

Übersetzung des Bytecodes bei Erreichen von 

Schwellwerten 

z.B. Methode wird zum nten mal ausgeführt 

Wechsel zwischen den Interpretern bei 

Methodenaufrufen oder Returns 


Hardware Implementierungen der 

JVM 

Direkte Bytecode Prozessoren 

Bytecode als nativer Befehlssatz 

Zusätzliche Befehle für HardwareZugriffe + Garbage 

Collection 

CodeMorphing Prozessoren 

OntheFly Transformation des Bytecode in nativen 

Code des Zielprozessors 

Befehlssatzerweiterungen 

Prozessor versteht Bytecode und anderen Befehlssatz 


Direkte Bytecode Ausführung 

Interpretation der Bytecodes durch Mikroprogramm 

Probleme: 

Effiziente StackAbbildung 

➢ Stack meist im internen Speicher (Geschwindigkeit, 

Parallelität) 

➢ Besondere Behandlung bei Speicherüber/unterlauf 

Kein Pipelining 

Beispiele: 

➢ Befehle haben unregelmäßige Struktur 

➢ Komplexität der Operationen stark schwankend 

PicoJava II, Ajile aj100, JOP 


Java Optimized Prozessor 

Sehr einfacher BytecodeProzessor 

4 stufige Pipeline 

Abbildung des Bytecode auf Microcode 

Einfache Befehle: 1 Microcode 

Komplexe Befehle: Mehrere Microcode Befehle 

Aber: Viele komplexe Befehle werden in Java 

programmiert 

(benutzen dann nur die Bytecodes, die direkt auf 

Microcode abgebildet werden können) 


JOP Architektur 

Bytecode 

Fetch, translate 

and branch 

Microcode 

Fetch and 

branch 

Microcode 

Decode 

bytecode branch condition 

next bytecode microcode branch condition 

bytecode branch 

branch 

Stack 

Address 

generation 

Microcode 

Execute 

Stack 

RAM 


Code Morphing 

Quasi JIT in Hardware 

Ähnlich wie z.B. Transmeta Crusoe 

Vorteile: 

Keine Zwischenspeicherung des Compilats 

Einfache Einbindung nativen Codes (z.B.: 

Betriebssytem) 

Probleme: 

Direkte Abbildung von Stackpositionen auf Register 

Beschränkt durch Anzahl verfügbarer Register 

Beispiel: 

JStar von Nazomi (für ARM Prozessoren) 


Befehlssatzerweiterungen 

Prozessor versteht mehr als einen Befehlssatz 

Umschalten des Betriebsmodus, um Bytecode 

auszuführen 

Nicht implementierte Bytecodes führen zu 

Exceptions ⇒ Behandlung in Software 

Beispiel: 

Jazelle für verschiedene ARMArchitekturen 

Problem: 

➢ Nur Methoden mit max. 4 Stackpositionen können 

ausgeführt werden 


Thread Modelle 

Implementierung von JavaThreads 

Green Threads: 

Die gesamte VM läuft als ein OSThread/Prozess 

Native Threads: 

Jeder Java Thread läuft als ein OSThread 

Wahl des ThreadModells hat wesentlichen Einfluss 

auf: 

Code Umfang 

Portierbarkeit 

Echtzeitfähigkeit 


Green Threads 

Vorteile: 

Einfache Portierbarkeit 

(Zielsystem muss keine Threads beherrschen) 

Weniger Critical Sections 

Nachteile: 

➢ Geringerer Code Umfang 

Keine blockierenden Operationen in Threads erlaubt 

➢ Ummantelung aller Betriebssystemaufrufe nötig 

Benutzung von compiliertem Code 

➢ Verlust der Echtzeitfähigkeit 


Native Threads 

Vorteile: 

Einfacherer Aufbau der Interpretationsschleife 

(Keine Abfrage der Signalvariable nötig) 

Besseres Laufzeitverhalten 

Nachteile: 

Viele Mutexe nötig 

➢ Bei Synchronisation auf ein Objekt 

➢ Bei Garbage Collection 

Hoher Portierungsaufwand 

➢ OSspezifische Routinen für wait() und notify() 

Schlechtere Laufzeit bei ThreadErzeugung 


Native Routinen 

Werden benötigt für 

Den Zugriff auf Hardware 

Den Zugriff auf das Betriebssystem 

Für die Implementierung zeitkritischer Aufgaben 

(wenn z.B. kein JIT oder HotspotCompiler verfügbar) 

Implementierung des GarbageCollectors 

ThreadHandling 

Reflection + Serialisierung 

Klassische Realisierung: 

Java Native Interface (JNI) 


Native Routinen in Hardware 

Implementierungen 

CodeMorphing + Befehlssatzerweiterungen: 

Kein Problem, nativer Code verfügbar 

Direkte BytecodeAusführung 

Kein nativer Code verfügbar 

Lösung: Einführung neuer Bytecodes 

Peek 

➢ Liest Adresse vom Stack 

➢ Legt MEM(Adresse) auf den Stack 

Poke 

➢ Liest Adresse und Wert vom Stack 

➢ Schreibt Wert an MEM(Adresse) 


Native Routinen in Hardware 

Implementierungen (2) 

Durch Peek + Poke 

Implementierung des GC 

(entsetzlich langsam, z.B. ajile aj100) 

Implementierung des HardwareZugriffs 

Implementierung des ThreadHandlings 

Evtl. zusätzliche Bytecodes für 

ThreadHandling 

Peek+Poke für kleinere Datentypen (Bit, Byte) 

OS muss in Java impementiert sein 


Native Routinen Probleme 

Objekterzeugung: 

Nativer Code erzeugt neue Objekte 

Problemstellen: 

➢ Kein Speicher mehr frei ⇒ Garbage Collector läuft 

➢ Vorher erzeugte Objekte sind nicht referenzierbar 

(werden ja nur vom nativen Code referenziert) 

➢ Vorher erzeugte Objekte werden fälschlich freigegeben 

Lang laufende oder blockierende Routinen 

Bei Green Threads nicht erlaubt 

Programmierer muss sinnvoll programmieren 


JNI 

Standardisierte Schnittstelle für die Implementierung 

von nativen Routinen 

Native Routinen werden dynamisch 

nachgeladen(DLL, shared Library, ...) 

Bestandteil des Standards 

Problem: OS kann nicht dynamisch nachladen 

⇒ kein JNI nutzbar 

VM kann abfragen, welche Methoden in DLL 

implementiert sind 

Standard JDK: Statische Initialisierung von Object 

lädt DLL mit den nativen Routinen für API (java.lang) 


JNI (2) 

JNI bietet: 

Zugriff auf die Argumente der implementierten 

Methode 

Native Methoden zum Zugriff auf ObjektFelder 

➢ Auswahl durch symbolische Information 

➢ Resolution der Namen erforderlich 

Möglichkeit Ergebnisse zurückzugeben 

Möglichkeit Exceptions zu werfen 

Möglichkeit Objekte zu erzeugen 

Möglichkeit (Java)Methoden von Objekten aufzurufen 


JNI – Probleme in ES 

CodeUmfang für JN I: ca. 500KB 

Ursache: 

Behandlung aller Spezialfälle 

➢ Nativer Code ruft Java Methode auf 

➢ Zugriff auf statische Klassenfelder 

➢ ... 

Dynamisches Nachladen 

Zugriffs und Hilfsfunktionen 

Alternative: 

KNI (KVM Native Interface) 


KNI 

Eincompilierte Tabelle aller nativen Methoden 

Vorteil: 

Immer implementierbar (sehr portabel) 

Effizienterer Übergang zw. Java und nativer Ebene 

Nachteile: 

Neue native Methoden: VM muss neu compiliert 

werden 

Tabelle kann sehr groß werden 

Kein Aufruf von Java Methoden aus nativem Code 

heraus möglich 


KNI Eigenschaften 

Resolution nativer Routinen: 

Suche nach nativen Routinen beim Klassenladen 

CodeZeiger in MethodenStruktur zeigt auf Adresse 

des nativen Codes 

Alle nativen Routinen haben gleiche Signatur 

Zugriff auf Stack 

➢ Lesen der Argumente 

➢ Ablegen des Ergebnisses 

Rückgabewert kann Exception spezifizieren 

Besondere Behandlung blockierender Routinen 

erforderlich 


KNI Probleme 

VMspezifische Techniken für 

Zugriff auf Argumente 

Zugriff auf Objektfelder 

Objekterzeugung (mit GCProblematik) 

Keine Unterstützung für Aufruf von JavaMethoden 

aus nativem Code heraus 

Wird in der Praxis aber auch selten gebraucht 

Sehr viel Disziplin nötig 


Ein/Ausgabe 

Zwei wesentliche Bereiche: 

DateiIO 

SocketIO 

Wesentliches Problem: 

IOAufrufe können blockieren 

Bei Green Threads nicht erlaubt 

Lösung je nach Betriebssystem: 

Asynchrones IO 

IOThreads für jeden Socket 

Separate IOThreads 


SocketIO 

Problematische Aufrufe: 

Connect 

Aktiver Verbingungsaufbau 

Write 

Kann hängen, wenn interne Puffer noch gefüllt 

Read 

Accept 

ServerSocket: Externe Verbindung kann zu 

beliebigem Zeitpunkt hergestellt werden 

(Close) 

Evtl. Noch warten, bis SchreibPuffer geleert sind 


Asynchrones IO 

Socket wird auf NonBlocking gestellt 

Aufrufe, die blockieren würden 

Kehren sofort zurück 

Liefern speziellen Fehlercode (EWOULDBLOCK) 

Zusätzlich wird asynchrone Benachrichtigung für 

Socket aktiviert: 

Wenn gewünschter IOAufruf möglich ist, wird ein 

Signal ausgelöst 

SignalBehandlung läuft asynchron zum Programm 


Asynchrones IO (2) 

Implementierung: 

Native Routine versucht den gewünschten Aufruf 

durchzuführen 

Ergebnis: EWOULDBLOCK 

Native Routine kehrt zurück 

Spezieller Rückgabewert an den Interpreter 

Interpreter stellt PC wieder auf Anfang des nativen 

Aufrufs 

Thread wird als wartend markiert 

Erneute Aktivierung des Threads: 

Gleicher nativer Aufruf wird noch einmal durchgeführt 


Asynchrones IO (3) 

SignalHandler: 

Bei eintreffendem Signal nicht klar, welcher Thread 

weiterarbeiten kann 

SelectAufruf prüft, für welchen Socket welche 

Operationen möglich sind 

Interne Tabelle liefert Informationen, welcher Thread 

auf welchen SocketZustand wartet 

Tabelle wird durch native Aufruf aufgebaut 

Betroffene JavaThreads wieder als lauffähig 

markieren 

Mutex zw. VM und SignalHandler erforderlich 


IOThreads für jeden Socket 

VM erzeugt 2 OSThreads für jeden Socket: 

1 zum Lesen (und für Accept) 

1 zum Schreiben (und für Connect) 

Nativer Aufruf stellt AufrufDaten in interne Struktur 

Nativer Aufruf signalisiert betroffenem Thread 

Arbeitsauftrag (z.B.: Semaphor, SystemEvent) 

Nativer Aufruf wird beendet (PC zurückstellen) 

IOThread erledigt Auftrag (mit synchronem IO) 

IOThread markiert betroffenen Thread als lauffähig 

Nativer Aufruf wird wiederholt (Daten aus interner 

Struktur) 


Separate IOThreads 

Ein zusätzlicher IOThread: 

Wartet in Select auf Beendung möglicher IOAufrufe 

Wenn gewünschter Aufruf möglich, betroffenen Java 

Thread als lauffähig markieren 

Problem: 

IOThread steht im Select und ein neuer Auftrag soll 

Lösung: 

angenommen werden 

Zusätzlicher Socket, der VM mit sich selbst verbindet 

Select wartet immer auch auf diesen Socket 

Unterbrechung durch Senden von Daten an sich selbst 


Garbage Collection 

Prinzipielles Problem: 

Auffinden nicht referenzierter Objekte 

Freigeben des Speicherplatzes dieser Objekte 

Welche Objekte werden referenziert ? 

Definition von WurzelReferenzen (StackFrames, Lokale 

Variablen, statische KlassenFelder, ...) 

Alle Objekte die direkt durch die Wurzeln referenziert 

werden (Objekte sind lebendig) 

Alle Objekte die von lebendigen Objekten referenziert 

werden 


GC: Konservativ vs. Vollständig 

Welche Einträge des Stacks sind Referenzen? 

VM kann Referenzen von anderen Typen unterscheiden: 

Menge aller lebendigen Objekte kann exakt bestimmt 

werden 

Vollständige GC möglich 

VM kann Referenzen nicht von anderen Typen 

unterscheiden: 

Elemente des Stacks können versehentlich als 

Objektreferenz interpretiert werden 

Menge der lebendigen Objekte kann nicht exakt 

festgestellt werden 

Konservative GC 


GC: Strategien 

Reference Counting 

zusätzlichen Zähler in Objekt aufnehmen (Zähler=0 

⇒ Objekt nicht referenziert) 

astore Bytecode: 

• Zähler des Objektes von überschriebener Referenz 

erniedrigen 

• Zähler des Objektes von neuer Referenz erhöhen 

Beim Löschen eines Frames Zähler aller Objekte 

erniedrigen 

⇒ sehr hoher Aufwand 

Tracing Garbage Collection 

Mark and Sweep 

Copying Collection 

Generational Collection 


Mark and Sweep 

Zweiphasiger Algorithmus: 

Phase 1 (Mark) 

Markierungen aller Objekte entfernen 

Von den Wurzeln aus alle Objekte markieren 

Von den markierten Objekten aus alle 

Referenzen verfolgen und Objekte markieren 

letzten Schritt wiederholen, bis alle 

Referenzen auf markierte Objekte zeigen 


Mark and Sweep (2) 

Phase 2 (Sweep) 

Heap sequentiell durchsuchen 

Alle nicht markierten Objekte freigeben 

Probleme: 

Nicht unterbrechbar 

(Kann modifiziert werden) 

Fragmentierung des Heap ( ⇒ Kompaktieren) 


Copying Collection 

Aufteilung des Speichers in zwei Bereiche 

Während des Verfolgens von Referenzen werden 

referenzierte Objekte in anderen Speicherbereich 

kopiert 

ForwardReferenzen werden an alten Platz gestellt 

Weitere Referenzen auf altes Objekt werden durch 

ForwardReferenz ersetzt 

Nach Beendigung: Alter Bereich leer, neuer Bereich 

kompakt 

Neue Objekte werden aus neuem Bereich allokiert 

Neuer Bereich voll ⇒ GC erneut starten 


Generational Collection 

Lebensdauer vieler Objekte sehr unterschiedlich: 

Sehr viele, (meist) kleine kurzlebige Objekte 

Wenige, (meist) große langlebige Objekte 

Konsequenz: 

Aufteilung des Heap in Generationen 

Jüngste Generation wird am häufigsten »collected« 

Älteste Generation wird selten »collected« 

Lebendige Objekte werden in die nächst ältere 

Generation kopiert 


EchtzeitProblematik 

Vorgestellte Verfahren sind nicht unterbrechbar 

Eintreffende Ereignisse werden erst bearbeitet, wenn 

GC beendet ⇒ inakzeptable Verzögerungen in 

EchtzeitSystemen 

Zwei mögliche Lösungen: 

1. Unterbrechbare GCVerfahren 

2. Inkrementelle GCVerfahren, mit kurzen 

GCPausen (z.B. TrainAlgorithmus, in Java SDK 1.3 

implementiert) 


Unterbrechbare GCVerfahren 

Problem: 

Halbfertiger Erreichbarkeitsgraph kann durch 

JavaProgramm verändert werden 

Veränderungen durch Programm müssen im 

Graphen mitgeführt werden 

Lösung: 

TriColoring 

➢ Zuordnung von Farben zu Objekten 

➢ Beschreibt Zustand des 

Erreichbarkeitsgraphen 


TriColoring 

Vor Traversierung Während Traversierung 

Nach Traversierung 

Nicht erreichtes Objekt 

Gerade betrachtetes Objekt 

Erreichtes Objekt 


Starke + Schwache Invariante 

Zwei mögliche Graphstrukturen: 

Schwache Invariante: 

Mindestens ein Weg zw. schwarzen und weißen 

Objekten geht über ein graues Objekt 

Snapshot at the Beginning 

Starke Invariante: 

Alle Wege zw. schwarzen und weißen Objekten gehen 

über graue Objekte 

Incremental Update 


Barrieren 

Verhindern Verletzung der Invarianten 

Lese und Schreibbarrieren möglich 

LeseBarriere: 

Bei Zugriff auf weißes Objekt wird dieses grau gefärbt 

Verletzt weder starke noch schwache Invariante 

SchreibBarriere: 

Unterscheidung für starke und schwache Invariante 


Schreibbarriere für die starke 

Invariante 

Problematisch: Veränderung an schwarzen Objekten 

Wird eine Referenz auf ein weißes Objekt in ein 

schwarzes geschrieben, dann wird das weiße Objekt 

grau gefärbt 


Schreibbarriere für die schwache 

Invariante 

Nicht neues Objekt wird betrachtet, sondern das alte 

Altes Objekt weiß: Dann grau färben. 


Referenzen 

Werden in Java durch Ableitungen der abstrakten 

Klasse Reference erzeugt 

Drei Unterarten verfügbar: 

SoftReference: Bleibt so lange wie möglich erhalten 

(Entfernen bei Speichermangel) 

WeakReference: Bleibt erhalten, solange noch 

Speicher da ist (Entfernen bei jedem GCLauf) 

PhantomReference: Bleibt nicht erhalten 

(Entfernen wann immer es der JVM gefällt) 


Referenzen – API 

Reference(Object o) oder 

Reference(Object o, ReferenceQueue rq) 

clear() setzt die ObjektReferenz auf null 

get() liefert die ObjektReferenz (oder evtl. null, 

wenn das Objekt freigegeben wurde) 

enqueue() Einreihen in die Warteschlange 

isEnqueued() bereits eingereiht? 


ReferenzWarteschlangen 

Verwalten ReferenceObjekte, die freigegeben wurden 

Müssen beim Erzeugen des ReferenceObjektes 

angegeben werden 

Methoden: 

poll(): Prüft ob Queue eine Referenz enthält 

remove(): Entfernt erstes Element der Queue 

(blockiert, wenn keine Referenz vorhanden) 

remove(long timeout): Wie remove(), aber mit 

Timeout 

enqueue(Reference r): Einreihen einer Referenz. 

Wird in der Regel vom GC aufgerufen

Folien zur Java Plattform - Professur für Mikrorechner - Technische ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?