JAVA/DSM A Platform for Heterogeneous Computing

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

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

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. DSM Prinzip Prozessor Prozessor Lokaler Speicher Lokaler Speicher Netzwerk

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 Variabelnglobal 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) Create twin X: Make X writable X: Release: twin Diff Diff X:

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ängige Codegenerierung (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