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