Kapitel 19 Der Ladezyklus Ali Jannessari

IPD Tichy – Lehrstuhl für Programmiersysteme

KIT – die Kooperation von Forschungszentrum Karlsruhe GmbH und Universität Karlsruhe (TH)

Assemblies 1 .NET-Modul = 1 .NET-PE-Datei (kann von WindowsLader direkt geladen werden). Aufbau einer .NET-PE-Datei (Portabel Executable): PE/COFF Headers

CLR Header

CLR Data Metadaten CIL (Code)

PE/COFF (Portable Executable/Common Object File Format) Kleines Programm für die Mitteilung an den DOS-Benutzer, dass diese Datei unter DOS nicht ausführbar ist (Wie Windows-PEDatei). 1

Kapitel 19 - Der Ladezyklus

Assemblies

PE/COFF Headers

CLR Header

CLR Data Metadaten CIL (Code)

CLR-Header, enthält: Versionsnummer der CLR Die Größe und Positionen einiger Metadaten-Tabellen Name der Methode, mit welcher die Ausführung beginnen soll (im Falle einer ausführbaren Datei)

Bei anderen Betriebssystemen muss die CLR explizit gestartet werden, um eine .NET-Applikation ausführen zu können (Portable): SSCLI (Rotor): clix Helloworld (clix ist das CLR-Program) Mono: mono Helloworld 2

Kapitel 19 - Der Ladezyklus

Assemblies Ein Modul allein ohne Manifest (spezielle Metainformationen) kann nicht direkt von CLR verwendet werden. Ein Assembly ist ein Container für verwaltete Module mit speziellen Metainformationen (Assembly = Modul + Manifest) Einheit für Auslieferung, Kapselung, Laden, Versionierung und Sicherheit (als EXE oder DLL) Einzel-Datei Assembly und Multi-Datei Assemblies

3

Kapitel 19 - Der Ladezyklus

Assemblies Multi-Datei Assemblies Das Primär-Modul verweist auf andere Module und Ressourcendateien enthält das Manifest und den Eintrittspunkt (.entrypoint)

Der Name einer Assembly ist der Name des Primär-Moduls

4

Kapitel 19 - Der Ladezyklus

Beispiel Assembly SFA (Einzel-Datei): .module SFA.exe

PE-Datei

CLR Header Manifest Ressource (z.B. ein Bild)

CIL-Code Typ 1

Typ 2

Typ 3

Ressource (z.B. ein Video)

Metadaten Typ 1

Typ 2

Typ 3

Im Manifest stehen die Informationen, die nötig sind, um alle Definitionen eines Assemblies zu finden

5

Kapitel 19 - Der Ladezyklus

Manifest Nur das Primär-Modul enthält die Assembly-Tabelle, die das Assembly identifiziert (und wird zuerst von CLR geladen) : Assembly

.assembly

0x20

Name des Assemblies (ohne Dateierweiterung, ohne Pfade) Version: Major.Minor.Build.Revision (je 2 Byte ) Sprache (Landes- und Sprachinformation) Hashalgorithmus: None, MD5,.. Attribute: None, SideByside,… Rechte, die zur Ausführung des Assemblies notwendig sind Publik Key File

.file

0x26

File-Tabelle: Liste aller Dateien (ohne PE-Datei des PrimärModuls), die zur Assembly gehören (IL-Tag: .file, TokenByte=0x26) 6

Kapitel 19 - Der Ladezyklus

Manifest Exported-Type-Tabelle: Typen, die in den anderen Modulen des Assemblies (nicht in Primär-Modul) definiert sind und außerhalb des Assemblies sichtbar sein sollen. ExportedType

.class extern

Namensraum und Name des Typs, Attribute (Sichtbarkeit, Layout, …) Verweis auf Implementierung und ...

7

Kapitel 19 - Der Ladezyklus

0x27

Multi-Datei Assemblies Wann? Wenn die einzelnen Module in verschiedenen Sprachen geschrieben wurden Wenn man vermeiden will, dass alle Teile einer Anwendung auf einmal geladen werden (z.B. verteilte Anwendungen)

8

Kapitel 19 - Der Ladezyklus

Beispiel: Multi-Datei Assemblies csc /target:module /out:priv.mod PrivateType.cs csc /target:module /out:pub.mod /addmodule:priv.mod PublicType.cs csc /addmodule:priv.mod,pub.mod MFAAPP.cs .Datei MFAAPP.exe .module MFAAPP.exe Manifest .assembly MFAAPP .file pub.mod .file priv.mod .class extern public PublicType

Metadaten .assembly extern mscorlib .module extern pub.mod .module extern priv.mod .class public App

CIL-Code 9

Kapitel 19 - Der Ladezyklus

.Datei pub.mod .module pub.mod Metadaten .assembly extern mscorlib .module extern priv.mod .class public PublicType

CIL-Code .Datei priv.mod .module priv.mod Metadaten .assembly extern mscorlib .class private PrivateType

CIL-Code

Zugriff auf exportierten Typ .Datei MFAAPP.exe

.Datei OtherApp.exe

.module MFAAPP.exe

.module otherApp.exe

Manifest

Manifest

.assembly MFAAPP .file pub.mod .file priv.mod .class extern public PublicType

.assembly OtherApp

Metadaten .assembly extern mscorlib .assembly extern MFAAPP .class public App

CIL-Code

2

1 3

pub.mod laden 4

Metadaten .assembly extern mscorlib .module extern pub.mod .module extern priv.mod .class public App

CIL-Code

Durch diese Informationen im Manifest wird das Assembly unabhängig Zero-Impact-Installation: Programminstallation ohne jede Nebenwirkungen 10

Kapitel 19 - Der Ladezyklus

Kapselung Ein Assembly bildet eine Kapsel um alle beteiligten Elemente und regelt damit: Sichtbarkeit (visibility): Welche Typen außerhalb des Assemblies sichtbar sind (Schlüsselwort privat: unsichtbar, Schlüsselwort public: sichtbar) Zugriffsrechte (accessibility): Von wo aus auf welche Komponenten zugegriffen werden darf private: innerhalb desselben Typs family: innerhalb desselben oder eines davon abgeleiteten Typs assembly: innerhalb desselben Assemblies famandassem: innerhalb desselben Typs und innerhalb eines von diesem abgeleiteten Typs desselben assemblies famorassem: innerhalb desselben oder eines davon abgeleiteten Typs oder innerhalb desselben Assemblies public: an beliebiger Stelle

11

Kapitel 19 - Der Ladezyklus

Private Assemblies Nur innerhalb eines Anwendungsverzeichnisses bekannt Wird nur von einer einzigen Anwendung verwendet Verschiedene Versionen liegen in unterschiedlichen Verzeichnissen Hat keinen „starken Namen“ (später) und identifiziert anhand eines einfachen Namens, z.B. “Stringer” Keine Versionsüberprüfung Kann nicht signiert werden Installation per Dateikopie Standardmäßig befinden sich Assembly und Anwendung im gleichen Verzeichnis Verzeichnis kann per .config-Datei definiert werden 12

Kapitel 19 - Der Ladezyklus

Private Assemblies Bibliotheken (DLLs) werden in folgenden Verzeichnissen gesucht: im Anwendungsverzeichnis in allen Verzeichnissen, die in einer eventuell vorhandenen Konfigurationsdatei (z.B. MyApp.exe.config) unter dem Tag angegeben sind: … … Vollständiger Quellcode: „Demo 5“ Kapitel 19 - Der Ladezyklus

Öffentliche (Shared) Assemblies können von allen Anwendungen benutzt werden stehen in einem systemweiten Repository: Global Assembly Cache (GAC) GAC kann gleichnamige Assemblies mit unterschiedlichen Versionsnummern enthalten  Side by Side Execution müssen durch einen starken Namen (strong name) identifiziert werden Können signiert werden Versionsüberprüfung durch die CLR

14

Kapitel 19 - Der Ladezyklus

Öffentliche (Shared) Assemblies Installation im Global Assembly Cache (GAC) mit SDK-Tools: al.exe oder gacutil.exe systemweiter „Speicherbereich“ normale Dateien keine Registry-Einträge, o. ä.

Friend Assemblies: nicht öffentlichen Typen einer Assembly für ausgewählte Assemblies sichtbar machen eine befreundete Assembly wird durch InternalvisibleTo deklariert using System;

// internal types & members visible to // the assembly called cs_friend_assemblies_2 [assembly:InternalsVisibleTo("cs_friend_assemblies_2")] class Class1 { ... } 15

Kapitel 19 - Der Ladezyklus

Starker Name (Strong Name) Manifest enthält einen starken Namen, der das Assembly eindeutig identifiziert Bestehen aus 4 Teilen: Name, Versionsnummer, Kultur und öffentlichem Schlüssel (public key) des Assemblies Der Name des Assemblies (z.B. A.dll, gleich wie name der PE-Datei) Die Versionsnummer des Assemblys: Major.Minor.Build.Revision (z.B. 1.0.1033.17) Im Quellcode: System.Reflection.AssemblyVersionAttribute festlegen oder per Assembly Linker (al.exe) Standardwert 0 für nicht angegebene Werte Build und Revision können im AssemblyVersion-Attribut durch * spezifiziert werden: [assembly:AssemblyVersion("1.2.*")] Der Compiler setzt dann passende Werte ein: Build: Anzahl der Tage seit 1.1.2000 Revision: Anzahl der Sekunden seit Mitternacht (Ortszeit) dividiert durch 2

16

Kapitel 19 - Der Ladezyklus

Starker Name (Strong Name) Die Kultur (culture) des Assemblies: Sprach und länderspezifische Information standardwert: Neutral durch System.Globalization.CultureInfo oder Al.exe festlegen

Der öffentliche Schlüssel (public key) des Assemblies identifiziert den Produzenten 128 Byte (1024 Bit) lang Für Referenzen auf Assemblies mit starken Namen verwendet man eine verkürze Version (Hashwert) von 8 Byte (64 Bit) = Public Key Token

Beispiele: MyAssembly, Version= 1.2.745.18000, Culture=en-Us, PublickeyToken=13a3f300fff94cef

AnotherAssembly, Version= 0.0.0.0, Culture=neutral, PublickeyToken=null

17

Kapitel 19 - Der Ladezyklus

Versionierung Aufbau der Versionsnummer:

Inkompatibel: Eine öffentliche Assembly ist grundsätzlich inkompatibel zum Klienten, wenn sich die Major- oder Minor-Version ändert Beispiel: neues Produktrelease Inkompatibel: Runtime wirft eine Type Load Exception

18

Kapitel 19 - Der Ladezyklus

Versionierung Vielleicht kompatibel: Ein öffentliches Assembly kann kompatibel zum Klienten sein, wenn sich die Build- bei gleich bleibender Major- und Minorversion ändert Beispiel: Servicepack

Runtime versucht, das Assembly mit der höchsten Revisions- und Buildnummer zu laden

QFE – Quick Fix Engineering: Ein öffentliches Assembly ist grundsätzlich kompatibel zum Klienten, wenn sich nur die Revision ändert In diesem Fall liegt ein so genannter Quick Fix Engineering (QFE) vor Beispiel: Security Hotfix

Runtime versucht, das Assembly mit der höchsten Revisions- und Buildnummer zu laden 19

Kapitel 19 - Der Ladezyklus

Versionierung Klient wird standardmäßig an die Version des öffentlichen Assemblies gebunden, die in seinem Manifest eingetragen ist. Dieses Verhalten kann per .config-Datei überschrieben werden

20

Kapitel 19 - Der Ladezyklus

Versionierung Es werden jene Bibliotheken geladen, die der erwarteten Versionsnummer entsprechen: Versionsnummer wird bei der Übersetzung gespeichert class A {...}

csc /t:library A.cs

A.dll (V 1.2.3.4)

class B { A a = new A(); ... }

csc /r:A.dll B.cs

B.exe merkt sich Versionsnummer von A.dll (V 1.2.3.4)

Versionsnummer wird beim Laden geprüft Aufruf: B

21

Kapitel 19 - Der Ladezyklus

● lädt B.exe ● findet darin Bezug auf A.dll (V 1.2.3.4) ● lädt A.dll in Version V 1.2.3.4 (auch wenn es andere Versionen von A.dll gibt)

Versionierung

Versionierung und öffentliche Assembly Vorgaben per .config-Datei definieren Option bindingRedirect – Klient soll eine ganz bestimmte Version eines Assemblies laden Name: Name des Assemblies Originator: Public Key des Assemblies, um Eindeutigkeit zu gewährleisten oldVersion: Version, die nicht geladen werden sollen (ein Stern kennzeichnet alle Versionen) newVersion: Version des Assemblies, das geladen werden soll

Vollständiger Quellcode: „Demo 6“ 22

Kapitel 19 - Der Ladezyklus

Virtuelles Ausführungssystem (VES) Bestimmung der Version der CLR Jede .NET-Applikation entspricht dem Windows-PE-Dateiformat (unter Windows) „mscoree.dll“ ist wie eine kleine zentrale Schaltstelle zur Bestimmung die Version der CLR Die Funktion „_CoreExeMain“ aus „mscoree.dll“ wird von WindowsLader (außerhalb der CLR) aufgerufen Die richtige Version der CLR wird von Windows-Lader zur Ausführung der .NET-Applikation festgelegt Alles weitere ist dann die Sache der CLR

23

Kapitel 19 - Der Ladezyklus

Virtuelles Ausführungssystem (VES) Kontrolle und Ausführung unter CLR CLR muss den Eintrittspunkt ins Programm finden der Primär-Modul mit der Main-Methode (Schlüsselwort: .entrypoint)

Erste Aufgabe der Execution Engine Laden einer PE-Datei Die Name der Main-Methode ist im CLR-Header der PE-Datei angegebn

Metadaten Module (.Net-PE-Datei)

Zweite Aufgabe der Execution Engine

CIL

Laden eines Assembly Die zuständige Applikationsdomäne erzeugt ein Assembly-Objekt

Execution Engine Laden einer PE-Datei

AppDomain Laden eines Assemblies

24

Kapitel 19 - Der Ladezyklus

Virtuelles Ausführungssystem - Aufgaben Typsicherheit Speicherverwaltung (Speicherlayout, GC, …) JIT-Compilation Ausnahmebehandlung Maschinencode, GC- & EH-Tabellen Sicherheit Verifizierer + JIT-Compiler

AppDomain

Assemblyinfo: Modul- & Typliste

Sicherheits -politik

25

Kapitel 19 - Der Ladezyklus

Typinfo, Methodentabellen

Sicherheitsmanager

Assemblyrechte

Klassenlader

Applikationsdomänen (AppDomains) sind isolierte Bereiche im CLR-Prozess (= BS-Prozess) (leichtgewichtige Unterprozesse, aber ungleich Threads) Thread A Thread B Thread C AppDomain 1

AppDomain 2

AppDomain 3

schirmen Applikationen gegeneinander ab können individuell geschützt und konfiguriert werden umfassen (und isolieren) Assemblies, Module und Typen einer Applikation (logische Container) Methodentabellen der geladenen Typen statische Felder und Objekte der geladenen Typen 26

Kapitel 19 - Der Ladezyklus

Applikationsdomänen Mechanismus dass in einem Prozess mehrere Applikationen laufen lassen. ohne sich gegenseitig beeinflussen

Es wird immer die Standard-Applikationsdomäne angelegt. Zusätzliche Applikationsdomänen können entweder direkt im Code (System.AppDomain.CreateDomain) oder vom jeweiligen Host der CLR erzeugt werden. Applikationsdomänen können auch entladen werden, ohne die CLR zu beenden.

27

Kapitel 19 - Der Ladezyklus

Applikationsdomänen Pro CLR-Prozess gibt es einen domäneneutrale Bereich, der von allen Applikationsdomänen erreichbar ist. Die domäneneutrale Bereich enthält die Assemblies und Typen, die von alle Applikationsdomänen gemeinsam benutzt werden. Assemblies die von mehreren Applikationen verwendet werden, werden in jeder Applikationsdomäne unabhängig voneinander geladen. Typen und statische Felder usw. werden einmal pro Applikationsdomäne angelegt. 28

Kapitel 19 - Der Ladezyklus

Beispiel: Applikationsdomänen Mehrere Applikationen in einem Prozess ohne sich gegenseitig beeinflussen: Default-AppDomain

AppDomain 2

Assemblies & Module

Assemblies & Module

view.exe

System.Windows.Forms.dll

gui.dll bar.mod

System.Drawing.dll System.dll

App2.exe

System.dll

System.Windows.Forms.dll

Typen & Methoden Typen & Methoden BarChartApp

BarChartGui

BarChartControl System.Windows.Forms.UserControl

SSW.MyControl SSW.App2 System.Windows.Forms.UserControl

domänen-neutraler Bereich Assemblies & Module mscorlib.dll

Typen & Methoden System.Object

System.Int32

Execution Engine, Heap, Thread-Pool, ... Windows-Prozess 29

Kapitel 19 - Der Ladezyklus

Auffinden eines Assemblies (Assembly Resolver) Beim Laden eines unbekannten Assemblys: Name des gesuchten Assemblys Versionsinformationen, die beim Übersetzer festgelegt werden Informationen über die Applikationsdomäne, die das Assembly laden will Information aus diversen Konfigurationsdateien

Strategie für private Assemblies: im Verzeichnis der jeweiligen Applikation und Probing

30

Kapitel 19 - Der Ladezyklus

Auffinden eines Assemblies (Assembly Resolver) Probing verwendet folgende Informationen: Das Basisverzeichnis der Applikation, die ein Assembly laden will (System.AppDomain.BaseDirectory) Die Sprache (Culture) des Assemblies (Falls vorhanden) Den Namen des zu ladenden Assemblies Den Privaten Suchpfad der Applikation (System.AppDomain.RelativeSerachPath oder in der AnwendungsKonfigurationsdatei oder direkt im Code)

31

Kapitel 19 - Der Ladezyklus

Auffinden eines Assemblies Strategie für Öffentliche (Shared) Assemblies: (1)

Bestimmen der zu ladenden Version des Assemblies

(2)

Falls die gefundene Version schon geladen wurde, wird diese verwendet

(3)

Ist sie noch nicht geladen, wird sie zuerst im GAC gesucht

(4)

Wurde das Assembly im GAC nicht gefunden: Falls in einer Konfigurationsdatei eine Codebase (URI) angegeben wurde, wird nur an dieser Stelle gesucht. Falls es dort nicht ist, wird die Suche erfolglos abgebrochen. Andernfalls setzt das Probing ein.

32

Kapitel 19 - Der Ladezyklus

Auffinden eines Assemblies Beispiel Probing auf MyAssembly : MyAssembly, Version= 1.2.0. 0, Culture=neutral, PublickeyToken=13a3f300fff94cef Basisverzeischnis der Applikation: http:// ipd.ira.uka.de/

Privater Suchpfad: bin

33

Kapitel 19 - Der Ladezyklus

Beispiel: Probing Probing auf MyAssembly : Folgende URIs in der anegebenen Reihenfolge: http:// ipd.ira.uka.de/ MyAssembly.dll http:// ipd.ira.uka.de/ MyAssembly / MyAssembly.dll http:// ipd.ira.uka.de/ bin / MyAssembly.dll http:// ipd.ira.uka.de/ bin / MyAssembly / MyAssembly.dll http:// ipd.ira.uka.de/ MyAssembly.exe http:// ipd.ira.uka.de/ MyAssembly / MyAssembly.exe http:// ipd.ira.uka.de/ bin / MyAssembly.exe http:// ipd.ira.uka.de/ bin / MyAssembly / MyAssembly.exe

Probing mit Sprachmerkmal Culture=de-de http:// ipd.ira.uka.de/ de-de / MyAssembly.dll http:// ipd.ira.uka.de/ de-de / MyAssembly / MyAssembly.dll http:// ipd.ira.uka.de/ bin / de-de / MyAssembly.dll usw. 34

Kapitel 19 - Der Ladezyklus

Klassenlader Metadaten Module (.Net-PE-Datei) CIL Execution Engine Laden einer PE-Datei

AppDomain Laden eines Assemblies

Sicherheitsmanager Rechtevergabe

Klassenlader Laden eines Moduls

Laden eines Typs

35

Kapitel 19 - Der Ladezyklus

Klassenlader Die CLR hat nur einen Klassenlader (keinen benutzerdefinierten Klassenlader wie in Java) Metadaten eines Assemblies werden vor allem betrachtet (für Typsicherheit und Konsistenzprüfungen) Laden eines Typs T (1) (2) (3)

Bestimmung des für Objekte von T benötigten Speicherplatzes Bestimmung des Speicherlayouts für T-Objekte Auflösung aller Referenzen von T auf bereits geladene Typen Die konsistente Verwendung der Referenzen wird überprüft Namentliche Referenzen werden in direkte Verweise umgewandelt

36

Kapitel 19 - Der Ladezyklus

Klassenlader Laden eines Typs T (fortgesetzt) (4)

(5)

Prüfung der Konsistenz aller Referenzen von bereits geladene Typen auf T Referenzen von T auf noch nicht geladene Typen werden: Durch sofortiges Laden der referenzierten Typen aufgelöst, oder Nur registriert und ihre Konsistenz beim späteren Laden des referenzierten Typs geprüft

(6)

Erzeugung von Stummeln für alle implementierten Methode von T, die beim ersten Aufruf der Methode die JIT-Übersetzung des CIL-Codes auslösen

Sobald der Typ T geladen wurde, lassen sich Objekte davon erzeugen und seine Elemente verwenden.

37

Kapitel 19 - Der Ladezyklus

Klassenlader Die Konsistenzprüfungen der Klassenlader sind minimale Tests, die durchgeführt werden müssen. Der Verifizierer ist für die formale Prüfung der Typsicherheit (Verifikation) zuständig.

Notwendige Prüfung für die Typsicherheit durch den Klassenlader Alle Eingangswerte müssen die vorgeschriebene Typsignatur aufweisen Typsignaturen aller Methoden und Feldern müssen mit deren Implementierung übereinstimmen

Vermeidung von Pufferüberläufen z.B: verwendete String-konstanten in den vorgesehenen Puffern Platz haben

Ob die verwendeten Metadaten-Tokens auch korrekt in die entsprechenden Tabellen verweisen Usw. 38

Kapitel 19 - Der Ladezyklus

Klassenlader Viele diese Prüfungen werden auch durch den Übersetzer durchgeführt, aber Es ist nicht bekannt mit welchem Compiler das zu ladende Assembly erzeugt wurde also muss der Lader zur Laufzeit noch einmal prüfen.

39

Kapitel 19 - Der Ladezyklus

Verifizierer Execution Engine Laden einer PE-Datei

AppDomain Laden eines Assemblies

Sicherheitsmanager Rechtevergabe

Klassenlader Laden eines Moduls Laden eines Typs

JIT-Compiler Verifikation der CIL

Übersetzung in Maschinencode

40

Kapitel 19 - Der Ladezyklus

Verifizierer Die Verifizierer ist für formale Prüfung der Typsicherheit (Verifikation) eines Programms vor seiner Übersetzung in Maschinencode zuständig Verifikation ist optional ein hohes Maß an Sicherheit

Typsichere Programme greifen nur auf Speicherbereiche die tatsächlich für sie eingerichtet werden Objekte werden nur über ihre Schnittstelle verwenden Objekte in eine gemeinsame Addressraum zu halten  keine etwaige Sicherheitsprüfungen

41

Kapitel 19 - Der Ladezyklus

Verifizierer Verifizierer ist ein Teil des JIT-Übersetzers und daher wird auch nur für einzelne Methoden aufgerufen, ohne den Kontext dieser Aufruf zu kennen Die Verifizierer untersucht den CIL-Code und nimmt eine Kontrollflussanalyse mit Hilfe der Typinformationen vor, um zu zeigen, dass: der Code typsicher ist, falls die Typinformationen korrekt sind und die Implementierung die Korrektheit der Typinformation garantiert.

42

Kapitel 19 - Der Ladezyklus

Verifizierer Der CIL-Code wird durch den Verifizierer in vier Kategorien eingeteilt: Ungültig Syntax entspricht nicht dem CIL-Format oder enthält undefinierte Befehlcodes Keinen Maschinencode von JIT-Compiler wird erzeugt

Gültig Syntax entspricht dem CIL-Format Enthält Anweisungen, die nicht Typsicher sind (z.B. Zeigerarithmetik) Maschinencode lässt sich erzeugen

43

Kapitel 19 - Der Ladezyklus

Verifizierer Typsicher Untermenge der gültigen Kategorie Alle Anweisungen halten sich streng an die Verträge, die die referenzierten Typen implementieren

Verifizierbar Eine echte Teilmenge der letzten Kategorie (Typsicher) Es kann bewiesen werden, dass CIL-Code typsicher ist. Es ist nicht möglich alle typsicheren Programme zu verifizieren.

44

Kapitel 19 - Der Ladezyklus

JIT-Compiler (Jitter im VES) Die Übersetzung von Programmcode ist dynamisch: Jede Methode wird erst dann übersetzt, wenn sie zum ersten Mal aufgerufen wird.

JIT-Übersetzung (JITten im VES) Ein Methodenaufruf erreicht zuerst den Stummel erzeugt von Klassenlader. Stummel enthält Informationen über den JIT-Status der Methode ob sie bereits in Maschinencode übersetzt wurde oder nicht

Falls der JIT-Status zeigt, dass kein Maschinencode für die Methode vorliegt: Der JIT-Compiler wird aktiviert und die Methode in Native Image Code übersetzt Die Informationen im Stummel wird aktualisiert 45

Kapitel 19 - Der Ladezyklus

JIT-Compiler (Jitter im VES) JIT-Übersetzung (JITten im VES) - fortgesetzt Zukünftige Aufrufe der übersetzten Methode wird den erzeugten Maschinencode ausführen. Bei einer neuerlichen Programmausführung muss wieder übersetzt werden. Mit dem ngen.exe (Native Image Generator) es ist möglich, das Programm auf einmal in Maschinencode zu übersetzen und in den Native Image Cache zu legen (Prekompilieren).

46

Kapitel 19 - Der Ladezyklus

JIT-Compiler (Jitter im VES) CLR bietet drei verschiedene Laufzeit-Übersetzer: Standard-JIT-Compiler Führt unter Berücksichtigung der aktuellen Rechnerarchitektur und Konfiguration Codeoptimierungen durch.

EconoJIT Besonderes sparsam mit Zeit und Speicherresourcen Unkomplizierte Portierung auf beliebige Plattformen wegen der Einfachheit und Sparsamkeit Erzeugter Maschinencode wird wieder weggeworfen Große CIL-Programme können mit sehr beschränktem Speicheplatz auskommen

Geeignet für eingebettete Systeme (z.B.: Mobile Gräte,…)

47

Kapitel 19 - Der Ladezyklus

JIT-Compiler (Jitter im VES) OptJIT (Keine Unterstützung vom Microsoft mehr) versteht nur eine Untermenge von CIL: „OptIL“ OptIL enthält zusätzliche Informationen, die Compiler-Optimierungen vorwegnehmen. gleichwertiges Ergebnisse wie standard-JIT und auch fast so Sparsam wie EconoJIT OptJIT setzt einen optimierende Source-to-CIL-Compiler voraus Zusatzinformationen über den Kontrollfluss, Registerallokation, etc. sind vorhanden ein Teil des JIT-Aufwands wird von der Laufzeit in die Übersetzungsezeit vorverlegt

Standardisierte Schnittstelle zwischen der CLR und JITCompiler Verwendung von benutzerimplementierten JIT-Compilern (hohe Flexibilität, möglich ab .Net 3.0) 48

Kapitel 19 - Der Ladezyklus

Execution Engine Laden einer PE-Datei

AppDomain Laden eines Assemblies

Virtuelles Ausführungssystem

(VES)

Sicherheitsmanager Rechtevergabe

Klassenlader

erste Verwendung eines noch nicht geladenen Assemblies

Laden eines Moduls

Laden eines Typs erste Verwendung eines noch nicht geladenen Typs

JIT-Compiler Verifikation der CIL

Übersetzung in Maschinencode erster Aufruf einer nicht übersetzten Methode eines geladenen Typs

Managed Native Code

Codemanager Ausführung des Programms

49

Kapitel 19 - Der Ladezyklus

Garbage Collection Exception Handling Sicherheitsprüfung

erste Verwendung eines noch nicht geladenen Moduls eines geladene Assemblies