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)

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

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

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

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

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

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

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

Prozessor Netzwerk Lokaler Speicher DSM Prinzip

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

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

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

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

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

Treadmarks Ziel - Reduzierung des Kommunikationsumfangs In der Verwaltung von Datenkonsistenz

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

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

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

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

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

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

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)

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

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

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

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

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“

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

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

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