JAVA/DSM A Platform for Heterogeneous Computing Serge F. Possono M. Technische Universität Muenchen (TUM) Lehr- und Forschungseinheit Informatik X Rechnertechnik.

Präsentation zum Thema: "JAVA/DSM A Platform for Heterogeneous Computing Serge F. Possono M. Technische Universität Muenchen (TUM) Lehr- und Forschungseinheit Informatik X Rechnertechnik."—  Präsentation transkript:

1 JAVA/DSM A Platform for Heterogeneous Computing Serge F. Possono M. Technische Universität Muenchen (TUM) Lehr- und Forschungseinheit Informatik X Rechnertechnik und Rechnerorganisation/ Parallelrechnerarchitektur Themensteller:Prof. Dr. Michael GerndtProf. Dr. Michael Gerndt (SS 2001)

2 Übersicht TUM - Design von JAVA/DSM - Einige Programmiermodelle(DSM) - Motivationen

3 Problemstellung Hardware Unterschiede -Verschiedene Darstellung von Daten -Kodeanpassung für jede Architektur

4 Verteilte Beschaffenheit des Systems -heterogene Systeme sind auch verteilte Systeme -Notwendigkeit von Kommunikation zwischen Maschinen -Konvertierung von komplexen Daten

5 Einige Programmiermodelle Message Passing - message passing libraries.Basisfunktionen: send(), receive().Datenkonvertierungsroutinen: pack(), unpack().Keine Unterstützung von komplexen Daten

6 -Remote procedure call (RPC).Schnittstelle mit spezifischen Funktionen.automatisches Ein-/ und Auspacken von Nachrichten. Definition der Schnittstelle.Sichtbarkeit des Darstellungsunterschiedes von Datenwerten

7 -Java/RMI (verbessertes RPC).Referenzierung von Objekten zwischen Maschinen.Referenzierung und Replikation von Objekten möglich.Sichtbarkeit der Kohärenzverwaltung von Objektkopien (Replikationen)

8 DSM Gemeinsamer Adressraum in einem Netzwerk NUMA-Modell Zwei Klassen von DSM - Hardwarebasierte DSM -Softwarebasierte DSM

9 Prozessor Netzwerk Lokaler Speicher DSM Prinzip

10 Hardwarebasierte DSM -Spezielle Hardwareunterstützung für die gemeinsamen Speicher -Anforderung von Daten durch MMU kontrolliert. -z.B. DASH,Alewife

11 Softwarebasierte DSM Seitenbasierte DSM -Linearer gemeinsam genutzter Speicher -Page-Fault Handler fördert Seiten -Probleme: Falshe-Sharing -z.B: IVY,Treadmarks

12 Softwarebasierte DSM Objektbasierte DSM -Strukturierter Adressraum mit gemeinsam genutzten Objekten -Migration und Replikation -Probleme: Zugriff auf die gemeinsamen Daten sehr aufwendig -z.B: Emerald,Clouds

13 Softwarebasierte DSM Shared-Variable DSM -einzelne gemeinsam genutzte Variabeln -drei Klassen von Variabeln *gemeinsame Variabeln global sichtbar *Synchronisationsvariabeln *normale Variabeln (in lokal Speicher)

14 Fähigkeit und Nachteile von DSM.Unsichtbarkeit des verteilten Zustandes des Systems. Zugriff auf komplexe Strukturen mit Zeiger.Sichtbarkeit von Hardwareunterschieden. Gebrauch von Sondercompiler für automatische Datenkonvertierung

15 Treadmarks Ziel - Reduzierung des Kommunikationsumfangs In der Verwaltung von Datenkonsistenz

16 Design von Treadmarks Notwendigkeit der Synchronisation -Vermeidung von „Data Race“ Synchronisationsfunktionen - Locks (acquire,release) - Barriers

17 Lazy Release Konsistenz Konsistenzverwaltung zwischen dem letzten releaser und dem neuen acquirer Verringerung von Kommunikationsumfang

18 Multiple-Writer Protocols Mehrere Schreiber können gleichzeitig auf eine Seite zugreifen Benutzung von Diffs - Reduzierung von Bandwidth

19 Write(X) X: Create twin Make X writable X: twin X: Diff Release:

20 Programmieren mit Treadmarks Die Datei Tmk.h bietet eine Schnittstelle zu Treadmarks Die wichtigsten Funktionen der Schnittstelle: -Startup -Speicher Allokation -Synchronisation -Termination

21 Programmieren mit Treadmarks Die Routine Tmk_startup initialisiert die Treadmarks library und erstellt Prozesse auf anderen Maschinen. Die Routine Tmk_malloc kümmert sich um die Speicherallokation. Mit Tmk_free wird ein Speicherplatz freigegeben. Der Ruf von Tmk_exit beendet einen Prozess

22 Programmieren mit Treadmarks Die Locks werden während die Durchführung von Tmk_startup hergestellt und initialisiert Übernahme der Lockkontrolle: Tmk_lock_acquire (lock_identifier) Locksfreigabe: Tmk_lock_release(lock_identifier)

23 Warum Java ? Portabilität - ArchitekturunabhängigeCodegenerierung (dank JVM) - Unsichtbarkeit der Maschinenarchitektur

24 Warum DSM ? Gemeinsamer Adressraum von physikalisch getrennten Speichern automatischeVerwaltung von Kommunikation zwischen Maschinen

25 Design Von Java/DSM Eine JVM für jeden Maschine (Knoten) Objekte werden in verteiltem Adressraum gespeichert Unterstützung von Java API Keine Migration von Threads zwischen Maschinen Keine Unterschiede zwischen entfernten und lokalen Objekten

26 Speicher Verwaltung Garbage collection wird unabhängig auf jeder Maschine ausgeführt Entfernte Referenzen zu lokalen Objekten sind bekannt um falsche Vernichtung zu vermeiden

27 Garbage Collection Algorithmus Der GC auf jeder Maschine verwaltet zwei Listen Die export Liste für entfernte Referenzen zu lokalen Objekten Die import Liste für Referenzen zu entfernten Objekten Benutzung von „weighted reference counting“

28 Datenkonvertierung Der handle von einem Objekt zeigt auf seinen body und zu einer Struktur, die den Typ von jedem Feld enhält Objekte auf einer Seite haben die gleiche Grösse Der body enthält einen Rückzeiger zum handle

29 Änderungen in JVM Eine Treadmarksroutine ladet den heap Klassen sind in dem gemeinsamen Speicher Jedes Objekt zeigt auf seinen handle (Unterstützung von Datenkonvertierung)

30 Zusammenfassung Hardwareunterschiede und Kommunikationsbedürfnisse Message Passing und DSM lösen nicht alle Probleme Java/DSM hat zu einer leichten Änderung von der JVM geführt