Upload
dedrich-leffel
View
103
Download
1
Embed Size (px)
Citation preview
JAVA/DSMA Platform for Heterogeneous
ComputingSerge F. Possono M.
Technische Universität Muenchen (TUM)Lehr- und Forschungseinheit Informatik X Rechnertechnik
und Rechnerorganisation/ Parallelrechnerarchitektur Themensteller:Prof. 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 Prozessor
Netzwerk
Lokaler Speicher
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 writableX:
twin
X:
Diff 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