TU BRAUNSCHWEIG
| Carl-Friedrich-Gauß-Fakultät | Informatik
Informatikzentrum

NVRAM meets Java: Erweiterung einer Java-Laufzeitumgebung um die Unterstützung von nicht-flüchtigen, Byte-adressierbaren Speicher

BetreuerJohannes Behl
ProfessorProf. Dr. Rüdiger Kapitza
Projekttclouds
refit
IBR GruppeDS (Prof. Kapitza)
ArtBachelorarbeit, Masterarbeit, Projektarbeit, Studienarbeit, Diplomarbeit
Statusvorläufig

Einleitung

Wenn es um Speichersysteme geht, so stehen sich heutzutage zwei Welten gegenüber: Auf der einen Seite gibt es die schnellen, Byte-adressierbaren Speicher, deren Gedächtnis jedoch eine ständige Energiezufuhr voraussetzt, ohne die sie schlagartig alles vergessen, und die eine relativ geringe Speicherdichte aufweisen. Auf der anderen Seite stehen nicht-flüchtige Speicher, mit hoher Speicherdichte, die nur blockweise und obendrein recht langsam angesprochen werden können.

Die nähere oder mittlere Zukunft verspricht indes, diese zwei Welten zu versöhnen: Speichertechnologien wie Phase-Change-Memory oder Spin-Transfer-Torque-Memory stellen schnelle, Byte-adressierbare und gleichzeitig nicht-flüchtige Speicher mit hoher Dichte in Aussicht. Obwohl diese Technologien ebenso für Sekundärspeicher eingesetzt werden können, scheint ein Einsatz als Hauptspeicher die wesentlich lohnenswertere Alternative zu sein.

Problem

Allgemein stellt sich die Frage, welche Auswirkungen hat der Einsatz von nicht-flüchtigem Hauptspeicher (Non-Volatile Random Access Memory, NVRAM) auf unsere aktuell eingesetzten Algorithmen und Softwaresysteme. Ebenso bring NVRAM einige Herausforderungen mit sich:

  • Koexistenz: Unter Umständen wird NVRAM normalen DRAM nicht komplett aus den Systemen verdrängen, sondern ergänzend eingesetzt werden. So stellt sich die Frage, wie mit dieser Koexistenz auf den verschiedenen Softwareebenen umgegangen wird.
  • Konsistenz: Schon heute ist darauf zu achten, dass Daten auf Sekundärspeichern konsistent bleiben bzw. Inkonsistenzen beseitigt oder zumindest erkannt werden, selbst wenn es zwischenzeitlich zum Stromausfall oder sonstigen Störungen kommt. Für den Hauptspeicher ist dies bisher unerheblich, da er bei einem Neustart ohnehin komplett neu gefüllt werden muss. Mit dem Einzug von NVRAM ist Konsistenz auch im Bereich des Hauptspeicher ein gewichtiges Problem.
  • Alterung: Theoretisch macht NVRAM die Initialisierung beim Neustart für weite Teile des Systems überflüssig. Dennoch müssen von Zeit zu Zeit Aktualisierungen an der Software vorgenommen werden und auch das berühmt berüchtigte Neustarten zur Beseitigung von erkannten und unerkannten Fehlern wirft bei der Verwendung von NVRAM neue Probleme auf.
  • Haltbarkeit: Die Anzahl an Schreibzugriffen, die NVRAM-Zellen verkraften, ist begrenzt.
  • Asymmetrie: Selbst wenn die Zugriffszeiten beim Lesen ungefähr denen von DRAM entsprechen sollten, beim Schreiben werden nicht-flüchtige Speicher bis zu einer Größenordnung langsamer sein.

Aufgabenstellung

Ziel dieser Arbeit ist es, eine Java-Laufzeitumgebung zur Verfügung zu stellen, die sowohl auf die Besonderheiten von NVRAM Rücksicht nimmt, als auch Programmen in geeigneter Weise den Zugriff auf diesen nicht-flüchtigen, Byte-adressierbaren Speicher ermöglicht.

Dazu müssen unter anderem das Zusammenspiel zwischen NVRAM, Betriebssystem und Laufzeitsystem und die Auswirkungen von NVRAM auf die Speicherverwaltung der JVM untersucht werden. Ferner gilt es, sich mit softwarebasiertem transaktionalem Speicher und bestehenden Persistenzsystemen für Java auseinanderzusetzen und zu prüfen, inwieweit sich diese Techniken in einem mit NVRAM ausgerüstetem System einsetzen bzw. anpassen lassen.

Für die Entwicklung der erweiterten Laufzeitumgebung steht ein aktuelles System bereit, das schon jetzt NVRAM auf Basis spezieller Speichermodule, die neben normalen DRAM auch Flash-Speicher beherbergen, zur Verfügung stellt.


aktualisiert am 07.10.2014, 06:30 von Johannes Behl
printemailtop