Virtuelle Maschinen. Semesterarbeit von Michael Mugglin an der Universität Bern. Sommersemester

Transkript

1 Virtuelle Maschinen Semesterarbeit von Michael Mugglin an der Universität Bern Sommersemester

2 Inhaltsverzeichnis 1.) Geschichte der virtuellen Maschine... S. 3 2.) Warum braucht es eine virtuelle Maschine und welche Probleme löst eine VM?... S ) Hauptanwendungsgebiet: Portabilität... S. 5 3.) Wo befindet sich eine virtuelle Maschine?... S ) Was macht eine virtuelle Maschine?... S. 8 4.) Einzelne virtuelle Maschinen... S ) IBM S ) UNIX..... S ) Java..... S ).Net.... S ) Smalltalk... S.19 5.) Zusammenfassung... S.21 6.) Quellen... S

3 1.) Geschichte der virtuellen Maschine Die Idee einer virtuellen Maschine war nicht immer klar definiert und war bis etwa Mitte der sechziger Jahre nicht wirklich vorangetrieben worden. Um 1965 herum hat IBM sich mit innovativen Ideen im Bereich Computer befasst und wollten diese auf ihre Effizienz testen. Die Forscher brauchten nun eine Umgebung, in der sie die verschiedenen neuen Entwicklungen miteinander vergleichen konnten. Sie mussten ein System entwickeln, das es ihnen ermöglichte, die neuen Features, an denen sie arbeiteten, an und aus zu schalten, um die unterschiedliche Performance messen zu können. Dieses System musste in der Lage sein, das ganze System in einzelne, kleinere Systeme teilen zu können. Diese kleinen Teile mussten unabhängig auf ihre eigenen Ressourcen zugreifen können, um so die Tests vergleichbar zu machen. Sie kamen zum Schluss, dass die Idee der virtuellen Maschine sehr nützlich für ihre Interessen sei. Nach diesen Experimenten entwickelte IBM die Idee weiter und verkaufte bald ihre erste virtuelle Maschine als eigenes Betriebssystem. Dieses Betriebssystem eignete sich hervorragend für mehrere Benutzer ( Multi-User). Viele Unternehmen und Universitäten nutzen dieses Betriebssystem, weil es ihnen gestattet, die Ressourcen ihres Mainframes mit vielen Benutzern zu teilen. Jeder Benutzer hat seine eigene virtuelle Maschine, auf der er arbeitet, und zugleich werden die Ressourcen mit allen anderen Benutzern geteilt, ohne dass diese beeinflusst werden. Dieses System ist bekannt unter dem Namen IBM System 370 (S/370) und IBM System 390 (S/390). Diese Systeme machen Gebrauch vom IBM VM/ESA Betriebssystem. In den siebziger Jahren wurde bei Rank Xerox zum ersten Mal an einem Projekt namens Smalltalk gearbeitet. Zum ersten Mal wurde der Gedanke von objektorientierter Programmierung konsequent verwendet. Die Idee dahinter war, dass eine plattformunabhängige, graphische Benutzeroberfläche entwickeln würde. Dies wurde mittels dem Konzept einer virtuellen Maschine verwirklicht. Mit dieser virtuellen Maschine von Smalltalk war es möglich, Programme, die in Smalltalk geschrieben wurden, auf vielen verschiedenen Plattformen auszuführen. Es gab viele Zwischenstufen von Smalltalk (Smalltalk-72, Smalltalk-74, Smalltalk-76,...), die jedoch nicht der Öffentlichkeit vorgestellt wurden, weil man mit enormen Effizienzproblemen kämpfte. Erst die Version Smalltalk-80 wurde in den achtziger Jahren veröffentlicht. Das Konzept von Xerox wurde danach von Apple aufgegriffen und hat die Entwicklung bei Apple massgebend beeinflusst. Die Idee der virtuellen Maschine wurde schon seit längerem gebraucht, um viele andere Probleme in der Computerwelt zu lösen. Probleme wie Computerprogrammportabilität und Designs eines Betriebssystems. Eine der frühen Implementationen für den Gebrauch einer virtuellen Maschine, war neben Smalltalk das UNIX Betriebssystem. Das UNIX Betriebssystem wurde zum ersten Mal im Jahre 1974 von Denise Richie und Ken Thompson von den Bell Labs der Öffentlichkeit vorgestellt. Die Idee ihres Betriebssystems wurde von den PDP-11 Computern adaptiert, die weit verbreitet waren bei Universitäten. Von den Universitäten war der Weg zur Industrie sehr schnell geschafft. Von 1980 bis 1985, begann die IEEE (the Institute of Electrical and Electronics Engineers) mit der Entwicklung von POSIX (Portable Operating System), um einen Standard für die UNIX Bibliotheken zu schaffen. Die Grundidee war, dass ein Softwareentwickler die Standardbibliotheken gebrauchen kann, um neue Programme zu schreiben und diese dann ohne Probleme auf das UNIX Betriebssystem zu portieren. Im Jahre 1990 veröffentlichte die IEEE einen Standard für die UNIX Kommandointerpreter und Hilfsroutinen, welcher die Schnittstelle zu den UNIX Prozessen spezifizierte. Ein Problem, das viele Programmierer über viele Jahre hinweg plagte, war das Entwickeln von wirklich portablen Programmen. Mit anderen Worten wollten Programmierer Programme schreiben, die auf allen Plattformen laufen würden. Mitte der neunziger Jahre wurde diese Idee des Gebrauchs einer virtuellen Maschine mittels der Programmiersprache Java verwirklicht. Es dauerte einige Zeit bis die Programmiersprache Java aus vielen verschiedenen Projekten entstand. Im Mai 1995 wurde das erste Java Development Kit (JDK) 1.0 von SUN Microsystems veröffentlicht, in dem auch die Java Virtual Machine (JVM) enthalten war. Mit der Einführung und der grossen - 3 -

4 Popularität der Programmiersprache Java erhielt das Konzept der virtuellen Maschine einen enormen Aufschwung, wie man aus der untenstehenden Grafik entnehmen kann. Java betreffende Veröffentlichungen Veröffentlichungen Virtuelle Maschine betreffende Veröffentlichungen ) Warum braucht man eine VM und welche Probleme löst sie? Das Konzept der virtuellen Maschine ist nicht neu in der Computerwelt, doch es ist ein Konzept, das viele Leute nicht kennen oder verstehen. Wenn sie ein typischer Computerbenutzer sind und sie brauchen das Internet um im World Wide Web zu browsen, dann haben sie ziemlich sicher schon mit einer virtuellen Maschine zu tun gehabt, wie etwa der virtuellen Maschine von Java. Für was sind virtuelle Maschinen eigentlich gut? Das Konzept der virtuellen Maschine wird in der Computerwelt meistens dazu gebraucht, um sehr wichtige Probleme zu lösen, aber sehr oft sind sie für den Benutzer unsichtbar, da die virtuelle Maschine typischerweise mit Programmen oder Betriebssystemen gebraucht werden. Die virtuelle Maschine wird heutzutage zum Lösen von vielen Problemen gebraucht: Das Aufteilen eines grossen Mainframes auf viele kleinere Computern (IBM Modell), das Ermöglichen einer grossen Portabilität von Programmen auf verschiedene Plattformen (Java Modell und Smalltalk Modell), das Erschaffen eines Betriebssystems (UNIX Modell), das Erreichen von Portabilität zwischen verschiedenen Betriebssystemen, das Teilen derselben Hardware unter vielen Programmen oder, dass ältere Programme auf neueren Computern laufen. Bei all diesen Gebieten spielt die virtuelle Maschine eine wichtige Rolle und übte (und übt) deshalb einen grossen Einfluss auf die heutige Computerentwicklung aus. Zuerst einmal wird der Begriff virtuell erklärt: Er stammt ursprünglich aus der Optik, um Objekte in einem Spiegel zu bezeichnen. Objekte in einem Spiegel sind Reflektionen eines physischen Objektes, aber die Objekte im Spiegel sind nicht wirklich physisch vorhanden. Das heisst, dass das Objekt im Spiegel genauso aussieht und sich genauso verhält wie das wirkliche Objekt, doch es existiert in Wirklichkeit gar nicht. Wir brauchen den Begriff hier im Zusammenhang mit einer virtuellen Maschine deshalb, um klar zu machen, dass wir möchten, dass unsere virtuelle Maschine - 4 -

5 sich exakt wie unsere reale Maschine verhält, jedoch ist unsere virtuelle Maschine nicht physisch vorhanden. Jetzt kommen wir zum Begriff Maschine : Alle Maschinen haben etwas gemeinsam, was das auch für Maschinen sind; sie haben alle eine gewisse Anzahl von Instruktionen, die sie erfüllen können. Diese Instruktionen können aufeinander aufgebaut werden, sodass neue, komplexere Instruktionen entstehen können. Es gibt viele Arten von virtuellen Maschinen, aber die gemeinsame Idee ist, dass sie eine Menge von Instruktionen simulieren. Jede virtuelle Maschine hat eine solche Menge von Instruktionen, auf die der Benutzer zugreifen kann, und bildet diese virtuellen auf die realen Instruktionen des Computers ab. Es gibt einige verschiedene Ansätze in der virtuellen-maschine-welt. Der Erste ist eine fast eins-zueins Abbildung der Instruktionen. Dieser Ansatz wird durch das Modell der virtuellen Maschine von IBM repräsentiert. Der zweite besteht aus einem Abbilden jeder Instruktion in der realen Maschine auf die virtuelle Maschine, repräsentiert durch die virtuelle Maschine von Java und Smalltalk. Die virtuelle Maschine von UNIX repräsentiert den letzten Ansatz. Dieses Modell bildet einige Instruktionen direkt ab, während andere über das Betriebssystem abgebildet werden. 2.1) Hauptanwendungsgebiet einer virtuellen Maschine: Portabilität Die Welt wäre einfach, wenn sich alle Programmierer auf einen Rechnertyp und eine Programmiersprache einigen könnten. Man würde dazu nur einen einzigen Compiler benötigen. Die Wirklichkeit sieht aber anders aus. Es gibt (aus gutem Grund) zahlreiche Rechnertypen und noch viel mehr verschiedene Programmiersprachen. Fast jeder Programmierer hat eine starke Vorliebe für eine bestimmte Sprache und möchte, dass seine Programme auf möglichst jedem Rechnertyp ausgeführt werden können. Bei einer Anzahl von n Programmiersprachen und m Maschinentypen würde dies n*m viele Compiler erforderlich machen

6 Bereits früh wurde daher die Idee geboren, eine virtuelle Maschine V zu entwerfen, die als gemeinsames Bindeglied zwischen allen höheren Programmiersprachen und allen konkreten Maschinentypen fungieren könnte. Diese Maschine wurde jedoch nicht wirklich gebaut, sondern man würde die Maschine auf jedem konkreten Rechnertyp nur emulieren, d.h. nachbilden. Für jede Programmiersprache müsste dann nur ein Compiler gebaut werden, der Code für die virtuelle Maschine V erzeugt. Statt n*m vieler Compiler benötigte man jetzt nur noch n Compiler und m Implementierungen von der virtuellen Maschine V auf den einzelnen Rechnertypen, insgesamt also nur n+m viele Übersetzungsprogramme ein gewaltiger Unterschied. Leider ist eine solche universelle virtuelle Maschine nie zustande gekommen. Neben der Vermutung, dass ihr Design eine bestimmte Sprache oder einen bestimmten Maschinetyp bevorzugen könnte, stand die begründete Furcht im Vordergrund, dass dieses Zwischenglied die Geschwindigkeit der Programmausführungen beeinträchtigen könnte. Ausserdem verhindert diese Zwischeninstanz, dass spezielle Fähigkeiten eines Maschinentyps oder spezielle Ausdrucksmittel einer Programmiersprache vorteilhaft eingesetzt werden können. Im Zusammenhang mit einer festen Sprache ist das Konzept einer virtuellen Maschine jedoch mehrfach aufgegriffen worden. Ein Java-Compiler z.b. übersetzt ein in Java geschriebenes Programm in Code für eine virtuelle Java-Maschine. Auf jeder Rechnerplattform für die ein Emulator für diese virtuelle Java-Maschine verfügbar ist, wird das Programm dann lauffähig sein. Weil man also bewusst auf die Ausnutzung besonderer Fähigkeiten spezieller Rechner verzichtet, wird die Sprache plattformunabhängig

7 3.) Wo befindet sich eine virtuelle Maschine? Ein Betriebssystem ist in Schichten aufgebaut. Zu unterst liegt die Hardwareschicht. Auf dieser Hardwareschicht befindet sich die Schicht des Betriebssystems. Der Kern des Betriebssystems benutzt die Instruktionen der Hardwareschicht, um den darüber liegenden Schichten gewisse Systemcalls bereitzustellen. Die Systemprogramme des Betriebssystems können nun auf diese Systemcalls oder direkt auf die Hardwareinstruktionen zugreifen. Die Systemprogramme stellen ihrerseits wieder Funktionen der darüber liegenden Schicht zur Verfügung. Diese Funktionen können von Benutzerprogrammen genutzt werden und so zu einem komplexen System zusammengefügt werden

8 Die Benutzerprogramme sehen alles unter ihrer Schicht als eine Maschine. In diesen Schichtenaufbau passt der Begriff der virtuellen Maschine hervorragend hinein. Das Betriebssystem schafft für uns Anwender die Illusion von multiplen Prozessen, das heisst, dass der Eindruck entsteht, dass das Betriebssystem mehrere Prozesse gleichzeitig verarbeiten könnte. Doch dies ist nicht ganz richtig. In Wirklichkeit steht ein ausgeklügeltes System von CPU Scheduling und virtuellen Speicher dahinter. Hier kommt die virtuelle Maschine ins Spiel. Die virtuelle Maschine erweckt den Eindruck, dass für jeden Prozess ein eigener Computer zur Verfügung stehen würde. Doch in Wahrheit steht nur eine identische, virtuelle Kopie der Hardware zur Verfügung. Somit können mehrere Prozesse zur gleichen Zeit laufen. Prozesse Prozesse Prozesse Kernel Kernel Kernel Virtuelle Maschine Hardware Die Ressourcen des physischen Computers werden dabei auf die virtuellen Maschinen aufgeteilt. CPU Scheduling wird benutzt, um allen Prozessen die Möglichkeit zu geben, die CPU zu benutzen. Somit wird der Eindruck erweckt, dass jeder Benutzer seinen eigenen Prozessor besitzt. Das Teilen der Ressourcen birgt aber auch einige Probleme in sich, wie zum Beispiel das Festplattensystem. Hat ein physischer Computer 3 Festplatten, jedoch möchte man aber sieben Festplatten für seine sieben virtuellen Maschinen haben. Klar, dass nicht eine Festplatte pro virtuelle Maschine zugeteilt werden kann. Die Lösung liegt in virtuellen Festplatten. Die physischen Festplatten werden dabei in kleinere virtuelle Festplatten aufgeteilt. Ein ähnliches Problem stellt sich in Bezug auf den Speicher, wo auch ein virtueller Speicher zum Einsatz kommt. Jedem Benutzer wird also eine eigene virtuelle Maschine bereitgestellt. Sie können darauf jedes Betriebssystem und jede Anwendungssoftware laufen lassen, die sie wollen. 3.1) Was macht eine virtuelle Maschine? Der Prozessor, der sich in der Hardwareschicht befindet, führt alle Berechnungen durch. Der Prozessor versteht aber nur eine sehr primitive Sprache, die sogenannte Maschinensprache. Diese Maschinensprachen sind nicht für die Benutzung durch Programmierer konzipiert und sind daher sehr schwierig zu lesen und noch schwieriger zu bearbeiten. Maschinenprogramme werden mithilfe von Übersetzern aus Programmen gewonnen, die in einer höheren Programmiersprache geschrieben wurden. Diese höheren Programmiersprachen sind für die Programmierer viel leichter zu verstehen. Bevor ein Programm, das in einer höheren Programmiersprache geschrieben wurde, auf einer konkreten Maschine ausgeführt werden kann, muss es in ein spezifisches Maschinenprogramm - 8 -

9 übersetzt werden. Dieses besteht aus einer Folge von Instruktionen, die die konkrete Maschine versteht und verarbeiten kann. Da jede konkrete Maschine mit einem eigenen Instruktionssatz implementiert wird, ist insbesondere die Codegenerierungsphase des Übersetzungsprozesses sehr maschinenabhängig und die Entwicklung eines portablen Übersetzers sehr aufwendig. Hier verlangt man nach einer virtuellen Maschine. Der Übersetzer übersetzt das Programm nicht in eine Folge von Instruktionen der konkreten Maschinen, sondern in eine Folge von Instruktionen einer virtuellen Maschine. Die Instruktionen der virtuellen Maschine werden Bytecode genannt, weil jeder Befehl in 8 bits, also in einem Byte, dargestellt wird. Um diesen Bytecode auszuführen, braucht es die virtuelle Maschine. Die virtuelle Maschine interpretiert diesen Bytecode dann in den spezifischen Maschinencode. Der Umweg über den Bytecode verlängert die Laufzeit von Programmen um das 2- bis 10fache. Jedoch bietet der Bytecode einige Vorteile, die den Nachteil der längeren Laufzeit aufwiegen. Ich möchte diese hier kurz erläutern: Programmgrösse Der Instruktionssatz einer konkreten Maschine ist vom Hersteller als optimale Schnittstelle zwischen Software und Hardware vorgegeben. Der Instruktionssatz einer virtuellen Maschine kann dagegen frei entworfen und der Quellsprache angepasst werden. Standardoperationen höherer Sprachen benötigen im Extremfall nur eine virtuelle Instruktion, anstelle mehrerer konkreter Instruktionen. Die Konsequenz ist ein sehr kompakter Objektcode. Zur genauen Bestimmung der Programmgrösse muss die konstante Grösse des Bytecode-Interpreters (z.b. der virtuellen Maschine von Java) allerdings mitgezählt werden. Codegenerierung Die Tatsache, dass für einen maschinenunabhängigen und der Quellsprache angepassten Instruktionssatz Code erzeugt wird, vereinfacht und beschleunigt die Codegenerierungsphase des Übersetzungsprozesses. Es ist nicht notwendig, Eigenheiten verschiedener Prozessoren zu berücksichtigen. Portabilität Die Unabhängigkeit des Instruktionssatzes einer virtuellen Maschine erleichtert auch die Portierung. In Bytecode übersetzte Programme sind auf jeder konkreten Maschine ablauffähig, auf der ein Bytecode-Interpreter installiert ist. Der Portierungsaufwand beschränkt sich somit auf die einmalige Portierung des Bytecode-Interpreters (in der Regel wenige Kilobyte). Ist der Bytecode- Interpreter zudem in einer weit verbreiteten Sprache wie C geschrieben, vereinfacht sich die Portierung noch einmal. Softwareentwicklung Durch die Emulation der virtuellen Maschine kann die Ausführung eines Programms vollständig kontrolliert werden. Der Zustand der virtuellen Maschine bestimmt durch Register, Keller, Programmzeiger etc. kann dynamisch analysiert und modifiziert werden. Für die Anbindung von Softwareentwicklungs-Werkzeugen zur komfortablen Fehlerkorrektur ist dies eine wichtige Voraussetzung. Da in Bytecode vorliegende Programme als Laufzeitdaten (nicht darstellbare Zeichenketten) repräsentiert sind, können weiterhin alternative Übersetzungstechniken wie Übersetzung zur Laufzeit und dynamisches Binden, unabhängig vom Betriebssystem und mit geringem Aufwand eingesetzt werden. Sicherheit Der Sicherheitsaspekt spielt bei Programmen, die über Computernetze (z.b. Internet) versendet werden, eine wichtige Rolle. Die Emulation der virtuellen Maschine stellt unter diesem Gesichtspunkt eine Sicherheitsebene dar, in der die Emulation von lokalen Ressourcen (Speicher Dateisystem, Drucker, etc.) einbezogen ist. Die Abbildung von virtueller nach realer Funktionalität - 9 -

10 kann kontrolliert und einem Programm unter Umständen der Zugriff auf bestimmte Ressourcen verwehrt werden. 4.) Einzelne virtuelle Maschinen 4.1) Das IBM virtuelle Maschine Modell Eine der meist verbreiteten virtuellen Maschine ist die virtuelle Maschine von International Buisness Machine (IBM). In diesem Modell ist jede virtuelle Maschine eine exakte Kopie der realen Maschine mit reduzierter Speicherkapazität. So kann ein grosser Mainframe Computer in viele kleinere virtuelle Maschinen mit sichtbar weniger Ressourcen als der Mainframe aufgeteilt werden. Eine virtuelle Maschine bildet die virtuellen Instruktionen aus dem Zwischencode auf reale maschinenspezifische Instruktionen ab. Im Falle der virtuellen Maschine von IBM wird dies durch eine eins-zu-eins Abbildung erreicht, indem jede virtuelle Instruktion auf eine äquivalente reale Instruktion abgebildet wird und auch so ausgeführt wird. Benutzer haben Zugriff auf alle Instruktionen der Maschine. Jetzt stellt sich die Frage, wie das virtuelle Maschine-Betriebssystem von IBM die Sicherheit garantiert, da ja alle Benutzer Zugriff auf alle Instruktionen der Maschine haben. Die Sicherheit wird durch die Abbildungsmethode gewährleistet, indem einfach gewisse kritische Instruktionen blockiert werden, wie z.b. beim Verändern des Prozessorsspeichers (Register). Wäre dies erlaubt, so könnte ein Benutzer den Inhalt einfach verändern und so andere virtuelle Maschinen, die zur selben Zeit laufen, beeinflussen und beeinträchtigen. Somit würden die virtuelle Maschinen nicht komplett unabhängig voneinander laufen und deshalb bestände die Möglichkeit, dass andere Umgebungen zum Abstürzen gebracht werden. Deshalb werden alle nicht kritischen Instruktionen direkt ausgeführt und die kritischen werden blockiert. Will ein Benutzer dennoch eine solche kritische Instruktion ausführen, so wird diese einfach von der virtuellen Maschine simuliert. Wie funktioniert die virtuelle Maschine von IBM? Das virtuelle Maschine-Betriebssystem ist das Gehirn der ganzen IBM virtuellen Maschine Architektur. Das ganze System, das Betriebssystem und die Hardware wird als virtuelle Maschine System betrachtet. Jedes derartiges System wird durch ein Programm, Control Program (CP) genannt, kontrolliert. Neben dem Verwalten der aktuellen physischen Hardware, kreiert dieses Control Program die virtuellen Maschinen für alle Benutzer des Systems, welche genaue Simulationen des System/370 oder des System/390 sind. Der wichtige Teil des IBM Konzepts einer virtuellen Maschine ist, dass ein Benutzer Programme laufen lassen, Daten speichern und sogar die virtuelle Maschine, auf der er arbeitet, zum Abstürzen bringen kann, ohne dass das ganze virtuelle Maschine System oder somit auch andere virtuelle Maschinen anderen Benutzern beeinflusst werden. Deshalb bietet das virtuelle Maschine Modell von IBM nicht nur das Teilen von Ressourcen, sondern auch das Beschützen dieser Systemressourcen an. Das Control Program ist der wichtigste Teil des virtuellen Maschine System. Es läuft direkt auf der Hardware des Mainframecomputers. Das Control Program verwaltet die Systemhardware, stellt Systemdienste zur Verfügung, wie z.b. das Aufstarten oder das Herunterfahren des Systems, wie auch das Planen und Ausführen von Anfragen... Das Control Program verwaltet auch das Erschaffen und Betreuen der einzelnen virtuellen Maschinen. Neben dem Control Program ist das Conversational Monitor System (CMS) eine weitere Hauptkomponente des virtuellen Maschine Systems. Dies ist ein komplizierter Name, doch hauptsächlich bietet das CMS die Betriebssystemdienste an, mit denen Benutzer arbeiten. Einige

11 dieser Dienste enthalten Dateisystembefehle, das Laden und Ausführen von Programmen, Speicherverwaltung, Bildschirm- und Fensterdienste, etc. Das CMS ist ein Betriebssystem, das entwickelt wurde für nur einen Benutzer zur gleichen Zeit. Jede virtuelle Maschine beinhaltet ihre eigene Kopie des CMS, sodass jedem Benutzer die gleichen Funktionalitäten und Schnittstellen geboten werden. Neben dem Control Program und dem CMS gibt es noch einige andere Teile. Doch diese Teile sind für die virtuelle Maschine nicht von Belang. Wie läuft nun die Abbildung der Instruktionen genau ab. Das CMS erlaubt es den Benutzern, die unkritischen Instruktionen direkt laufen zu lassen, ohne Einschränkung bei der Geschwindigkeit. Bei den kritischen Instruktionen sieht das anders aus. Eine kritische Instruktion bedeutet ja, dass ein Zustand einer anderen virtuellen Maschine verändert werden könnte. Z.B. möchte ein Benutzer eine Instruktion ausführen, die den Zugriff auf eine andere virtuelle Maschine eines anderen Benutzers ermöglicht. Das CMS würde eine solche Instruktion als kritisch markieren. Diese Instruktion wird dann dem Control Program mit einem speziellen Flag übergeben. Dies wird Interrupt genannt. Das Control Program erhält diese Instruktion und merkt, dass sie als kritisch markiert ist. Dann nimmt es diese Instruktion und führt sie mit Hilfe von speziellen Tests und Routinen aus. Durch die Tests wird dem Control Program klar, ob diese Instruktion simuliert werden kann oder ob diese Instruktion komplett blockiert werden muss. Falls das Control Program die Instruktion simuliert, merkt der Benutzer nichts von alldem. Falls die Instruktion blockiert werden muss, erhält der Benutzer eine Fehlermeldung und die Ausführung des Programms wird gestoppt. Zusammenfassung Das virtuelle Maschine System von IBM bietet einen Weg, grosse Systeme auf eine sichere Art auf viele Benutzer aufzuteilen. Mittels dem Simulieren der aktuellen Maschine für jeden Benutzer, bietet das IBM virtuelle Maschine System jedem Benutzer die gleichen Funktionalitäten und Ressourcen ohne die Privatsphäre eines Benutzers oder die Sicherheit in irgendeiner Weise zu beeinträchtigen. Das System ist nach dreissig Jahren der Entwicklung stabil genug, dass es weitverbreitet in der Industrie und an Universitäten eingesetzt wird. 4.2) Das UNIX virtuelle Maschine Modell Der Gebrauch von virtuellen Maschinen war eine erfolgreiche Methode, um viele Probleme in der Computerentwicklung zu lösen. Das virtuelle Maschine Konzept floss bei der Entwicklung von UNIX stark mitein. Das UNIX Betriebssystem ist eines der erfolgreichsten und respektiertesten Betriebssysteme in der modernen Computerwelt. Der weit verbreitete Gebrauch von UNIX war der Grund, warum die Eigenschaften der virtuellen Maschine umfangreich erforscht wurden. Das UNIX Betriebssystem braucht eine Reihe von unabhängigen Prozessen, um Benutzeranforderungen zu erfüllen. Die UNIX Prozesse können prinzipiell als eine virtuelle Maschine betrachtet werden, weil sie viele der Kriterien von anderen virtuellen Maschine Modellen entsprechen. Die UNIX virtuelle Maschine macht Gebrauch von identischen Kommandointerpretern, so genannten Shells, für jeden Benutzer. Diese Shells verhalten sich also ähnlich wie die virtuellen Maschinen von IBM. Jeder Benutzer hat seinen eigenen Kommandointerpreter. Der UNIX Kommandointerpreter kann als virtuelle Maschine betrachtet werden, weil jeder Interpreter eine unabhängige Entität aus einem kompletten Satz von Hardwareressourcen ist. Der Kommandointerpreter von UNIX handelt als Chef, der das Erzeugen von neuen Prozessen und das Zuweisen von Daten von einem Prozess zu einem anderen verwaltet, um den Anforderungen des Benutzers gerecht zu werden. Beim diesem Modell herrscht das Prinzip der Isolation und Separation von den Kommandointerpretern (Shells) von seinen Nachbarninterpretern

12 Die User Shells in der obigen Grafik können als virtuelle Maschine betrachtet werden. Der UNIX Prozess besitzt auch einen Dienst der virtuellen Maschine von Java, weil er die plattformunabhängigen Bibliothekenfunktionen braucht, die durch das Schichtendesign des Betriebssystems gegeben werden. Das UNIX Betriebssystem ist so konstruiert worden, dass es eine einheitliche Menge von unabhängigen Bibliotheksfunktionen liefert. Das UNIX Betriebssystem ist in Schichten aufgebaut, wobei jede einzelne Schicht einen Dienst für die nächste darüber liegende Schicht bereitstellt. Diese Standardisierung ermöglicht es den Benutzern, Programme auf verschiedenen Plattformen auszuführen. Dies ist möglich, weil UNIX den Standard POSIX braucht. Während der Programmcode für spezielle Programme immer noch für jede Plattform compiliert werden muss, ist der Programmcode der meisten Programme echt portierbar auf jede gängige UNIX Plattform, die die gleiche Menge von Funktionen unterstützt. Kommandointerpreter Standardbibliotheksfunktionen UNIX Betriebssystem Speicherverwaltung, Prozessverwaltung Hardware CPU, Speicher, Festplatten

13 4.3) Das Java virtuelle Maschine Modell Die Betrachtung einer virtuellen Maschine aus der Sicht von Java ist sehr verschieden als aus der IBM Sich. IBM s Idee war, das Aufteilen des Systemsspeichers und der Ressourcen auf einzelne exakte Kopien der aktuellen Maschine. Bei Java wird das System nicht aufgeteilt, sondern es wird eine virtuelle Maschine auf die reale Maschine aufgesetzt. Dieser Ansatz hat sich als sehr gut geeignet erwiesen bei Softwareentwicklern, die eine Maschine auf eine komplett andere Maschine emulieren wollten. Der Java-Compiler erzeugt dabei keinen spezifischen Maschinencode, sondern einen plattformunabhängigen Zwischencode, Bytecode genannt. Dieser Bytecode wird dann durch die virtuelle Maschine von Java ( JVM) auf den jeweiligen Plattformen interpretiert und ausgeführt. Dies ist vorteilhaft, weil es eine sehr hohe Portabilität ermöglicht. Falls die gleiche JVM auf zwei komplett verschiedenen Maschinen installiert ist, so läuft ein Java Programm auf beiden Maschinen problemlos, da sie auf der JVM beruhen und nicht auf dem System, auf dem sie laufen. In der obigen Abbildung kann der Interpreter als virtuelle Maschine verstanden werden. Wegen seiner hohen Portabilität, ist Java zur meist verbreiteten Programmiersprache im Internet geworden. Viele Webpages enthalten heute Javaprogramme, weil sie spezielle Dienste für das Anzeigen in einem Browser bereitstellen. Die virtuelle Maschine ist auch sehr klein. In anderen Worten, braucht sie keine grossen Speicherressourcen. Deshalb kann die virtuelle Maschine von Java auf vielen Maschinen laufen. Wie funktioniert die virtuelle Maschine von Java? Die virtuelle Maschine von Java ist eine abstrakte virtuelle Maschine. In anderen Worten ist sie in Software implementiert, die sich auf realen Hardwareplattformen und Betriebssystemen befindet. Javaprogramme werden für die virtuelle Maschine compiliert und nicht für das reale System selber. Das heisst, dass ein Programmierer sein Javaprogramme schreibt und dieses dann vom Java Compiler in Bytecode übersetzt wird. Dieser Bytecode kann als Maschinensprache für die virtuelle Maschine verstanden werden. Die virtuelle Maschine interpretiert diesen Bytecode als Sequenz von Instruktionen. Diese Instruktionen werden dann ausgeführt und erzeugen dann die gewünschte Ausgabe

14 Programmierer schreibt Javaprogramm Javaprogramm Java Quellcode Java Compiler Der Java Compiler generiert den Bytecode, der den Instruktionen des Programms entspricht Virtuelle Maschine von Java Die virtuelle Maschine von Java interpretiert den Bytecode und führt die Instruktionen aus Ausgabe Hardware und Betriebssystem Das System erhält die Instruktionen von der virtuellen Maschine und zeigt die gewünschte Ausgabe Wie aus der Abbildung hervorgeht, werden die Instruktionen, nachdem der Bytecode von der virtuellen Maschine interpretiert wurde, auf Instruktionen des Betriebssystems oder der Hardware abgebildet. Das heisst, dass die virtuelle Maschine von Java in Wirklichkeit Betriebssystem- und Hardwareinstruktionen verwendet, um die gegebenen Instruktionen abzuarbeiten. Deshalb muss die virtuelle Maschine eine mögliche Abbildung der Instruktionen auf jedes Betriebssystem oder Maschine, auf der sie installiert ist, anbieten. Dies ist der Grund, warum Java keine hundertprozentige Portabilität erreicht hat. Es ist möglich, dass die virtuelle Maschine von Java nicht für alle Maschinen oder Betriebssystemen implementiert wurde und deshalb auf diesen Systemen kein Javaprogramm laufen kann. Doch auf den meisten Plattformen gibt es eine solche Version der virtuellen Maschine. Die Basisteile Die virtuelle Maschine von Java kann in fünf Basisteile gegliedert werden: Bytecode-Anweisungen Register Stacks Heaps Speicherbereich für Methoden

15 Diese Teile können mit einem Interpreter, einem nativen Binärcode-Compiler oder gar einem Hardware-Chip implementiert werden. Auf jeden Fall müssen alle diese logischen abstrakten Komponenten der virtuellen Maschine in der einen oder anderen Form in jedem Java-System bereitgestellt werden. Die virtuelle Maschine und der unterstützende Code werden meist Laufzeit-Umgebung genannt. Der Java-Bytecode Die Bytecode-Anweisungen sind optimiert und deshalb schlank und kompakt. Sie wurden für das Internet ausgelegt, deshalb wurden zwischen Geschwindigkeit und Platzbedarf Kompromisse gemacht. (Angesichts der Tatsache, dass sich die Internet-Bandbreite und die Geschwindigkeit von Massenspeichern schneller erhöhen als die CPU-Geschwindigkeit, scheint das ein vernünftiger Kompromiss.) Wie bereits erwähnt, wird der Java-Quellcode in Bytecodes compiliert und in einer.class-datei gespeichert. Auf dem Java-System von Sun erfolgt das mit dem javac-werkzeug. Dabei handelt es sich nicht um einen herkömmlichen Compiler. Javac übersetzt den Quellcode in Bytecode, so dass dieses niedrigere Format nicht direkt ausgeführt werden kann, sondern von jedem Rechner weiter interpretiert werden muss. Das genau bringt uns aber die Vorteile der totalen Portabilität. Javaprogramm (MeinProgramm.java) Java Compiler (javac MeinProgramm.java) Java Bytecode (MeinProgramm.class) Register Die Register der virtuellen Java-Maschine sind mit den Registern eines»echten«rechners identisch. Register beinhalten den Zustand einer Maschine, beeinflussen ihren Betrieb und werden nach jeder Ausführung eines Bytecodes aktualisiert

16 Im folgenden eine Aufstellung der Java-Register: pc: Programmzähler, der bezeichnet, welcher Bytecode ausgeführt wird. optop: Ein Pointer ganz oben im Operanden-Stack, der zur Auswertung aller arithmetischen Ausdrücke dient. frame: Ein Pointer, der auf die Ausführungsumgebung der aktuellen Methode zeigt und einen Aktivierungsdatensatz für den Aufruf dieser Methode sowie relevante Debugging- Informationen enthält. vars: Ein Pointer, der auf die erste lokale Variable der momentan ausgeführten Methode zeigt. Die virtuelle Maschine definiert als Grösse dieser Register 32 Bits. Da die virtuelle Maschine primär auf Stacks basiert, nutzt sie zum Weitergeben oder Empfangen von Argumenten keine Register. Das ist Absicht und soll zur Einfachheit und Kompaktheit des Bytecodes beitragen. Stacks Die virtuelle Maschine von Java basiert auf Stacks. Der Rahmen eines Java-Stacks ist mit dem in herkömmlichen Programmiersprachen vergleichbar. Er enthält den Zustand eines Methodenaufrufs. Rahmen für verschachtelte Methodenaufrufe werden in diesem Rahmen gestapelt. Ein Stack dient zur Bereitstellung von Parametern für Bytecodes und Methoden und zum Aufnehmen der Ergebnisse. Jeder Stack enthält drei Datenmengen: die lokalen Variablen für den Methodenaufruf, die Ausführungsumgebung und den Operanden. Die Grösse der ersten zwei Elemente steht zu Beginn eines Methodenaufrufs fest, während der Operand grössenmässig bei der Ausführung des Bytecodes der Methode variiert. Der Operanden-Stack (32-Bit, nach dem LIFO-Prinzip (Last In, First Out)) wird zum Speichern der Parameter und Rückgabewerte der meisten Bytecode-Anweisungen verwendet. So erwartet der iadd-bytecode beispielsweise zwei Ganzzahlen (integer) oben auf dem Stack. Heaps Ein Heap ist derjenige Teil des Speichers, dem neu erstellte Instanzen (Objekte) zugewiesen werden. In Java hat ein Heap meist eine feste Grösse, wenn das Java-Laufzeitsystem gestartet wird. Auf Systemen, die virtuellen Speicher unterstützen, kann er aber nach Bedarf fast unbegrenzt wachsen. Da in Java Objekte automatisch der Müllbeseitigung ( garbage collection ) unterliegen, muss der Programmierer den einem Objekt (das nicht mehr benutzt wird) zugeteilten Speicher nicht manuell freigeben (und kann das auch nicht). Auf Java-Objekte wird indirekt zur Laufzeit über Handles - eine Art Pointer, der auf einen Heap zeigt - zugegriffen

17 Der Methodenbereich Wie die compilierten Codebereiche konventioneller Programmiersprachen speichert der Methodenbereich die Java-Bytecodes, die fast jede Methode im Java-System implementieren. Im Methodenbereich werden auch die zum dynamischen Verknüpfen benötigten Symboltabellen und andere zusätzliche Informationen gespeichert, z. B. zum Debugging. Zusammenfassung Der Hauptgedanke der virtuellen Maschine von Java ist, das Problem von der Portabilität von Programmen zu lösen. Die Frage ist, ob die virtuelle Maschine von Java dieses Problem wirklich löst. Die Antwort ist jein... Sie löst dieses Problem nicht völlig. Doch die virtuelle Maschine von Java ist eine sehr gute Lösung, die dieses Problem fast hundertprozentig löst, da die virtuelle Maschine nicht auf allen Plattformen implementiert wurde. Doch Java hat einen extrem hohen Grad an Portabilität erreicht. Java ermöglicht Programmierern Programme zu schreiben, die auf vielen verschiedenen Plattformen laufen und hat so bewiesen, dass sie eine gute und brauchbare Interpretation der Idee einer virtuellen Maschine ist. 4.4) Das.NET virtuelle Maschine Modell Die virtuelle Maschine von.net wurde von Microsoft entwickelt, damit ihre neuen.net Softwareprodukte nicht nur auf Intel PC s mit Windows laufen, sondern auch auf vielen anderen Plattformen. Die Common Language Runtime (CLR) ist die Basis der virtuellen.net Maschine. Sie stellt eine Ausführungsumgebung für.net-programme zur Verfügung. Wie in den anderen virtuellen Maschine Modellen ist auch die CLR in der Lage, Instruktionen in einer Zwischensprache auszuführen, die Microsoft Intermediate Language (MSIL) genannt wird. MSIL ist die direkte Abbildung des Microsofts Objektmodells, dem Virtual Object System (VOS). Einen Compiler in.net zu portieren, heisst, dass der Quellcode in die MSIL, analog dem Bytecode von Java und Smalltalk, übersetzt wird und nicht direkt in den spezifischen Maschinencode. Neu bei diesem Ansatz ist, dass dieses Konzept ausdrücklich unabhängig von der Programmiersprache ist. Eine Anwendung kann in verschiedenen Sprachen, etwa VisualBasic und C++, verfasst sein. Alle Sprachen greifen nicht nur auf dieselbe Bibliothek zurück, sondern nutzen eine einheitliche objektorientierte Schnittstelle, können also Klassen einander vererben etc. Die unmittelbare Zusammenarbeit zwischen verschiedenen Programmiersprachen ist neu und heute allenfalls deutlich umständlicher über externe Standards wie CORBA oder COM zu erreichen. Dies bringt zum Ausdruck, dass.net nicht nur für eine Programmiersprache entwickelt wurde, wie die virtuelle Maschine von Java, sondern einer Vielzahl von verschiedenen Sprachen zur Verfügung steht (momentan für 20 Programmiersprachen)

18 MSIL wurde für die on-the-fly Compilation geschaffen. Das heisst, dass der Zwischencode erst in den Maschinencode compiliert wird, wenn das Programm zum ersten Mal ausgeführt wird. Dies wird auch Just In Time -Compilation (JIT) genannt. Bei Java ist dies nur optional. Microsoft zog Konsequenzen aus den Erfahrungen mit der virtuellen Maschine von Java und legte bei der Entwicklung von.net besonderes Augenmerk auf die Performance der virtuellen Maschine. Die Resultate sind eindrücklich: Bei einem Test, bei dem ein Eiffelprogramm durch einen Standard C-Compiler, der Maschinencode erzeugte, übersetzt wurde und das gleiche Programm von.net ausgeführt wurde, konnten keine signifikanten Unterschiede in Bezug auf die Geschwindigkeit bemerkt werden, obwohl.net den Umweg über MSIL gehen musste. Die Unterschiede sind klar: Während Java ein interpreterorientiertes Design, wo JIT Compiler nur zweitrangig sind, die Portabilität enorm voranbrachte, stand beim Design von.net die Laufzeitperformance im Mittelpunkt der Entwicklung. Microsoft hat parallel zur Entwicklung von.net gleich eine.net-musterprogrammiersprache C# entwickelt, die aus vielen Programmiersprachen, wie etwa Java, Eiffel, C, C++,... entstanden ist. Wie funktioniert die virtuelle Maschine von.net? Die virtuelle Maschine von Microsoft bietet für die Softwareentwickler vieler Programmiersprachen eine Vielfalt von sinnvollen Mechanismen: Ausnahmebehandlung, Sicherheit, Speicherverwaltung, Speicherbereinigung, Debugginghilfen, Threadunterstützung und Compilation. Grundlage der CLR ist ein gemeinsamer Standard für objektorientierte Programmiersprachen (Common Language Specification, CLS) und für deren Typsystem (Common Type System, CTS). So wird es ermöglicht, dass.net mehrere Programmiersprachen verstehen kann. Jedoch muss die Programmiersprache sich diesem Standard anpassen. Bei.NET wird zwischen managed code und unmanaged code unterschieden. Managed code ist der Code, der in einer Programmiersprache geschrieben wurde, die die virtuelle Maschine von.net versteht, also dem CLS Standard entspricht, und deshalb auch in MSIL übersetzt werden kann. Unmanaged code ist derjenige Code, der nicht diesem Standard entspricht. Sämtlicher managed code wird unter der Kontrolle der CLR ausgeführt. Die CLR lädt die in MSIL vorliegenden Programme und übersetzt diese zur Laufzeit in maschinenspezifischen Code. Die CLR ist die Laufzeitumgebung für.net Programme. Sie basiert auf einer abstrakten Stack- Maschine, ähnlich wie Java, die ausschliesslich Anweisungen des Zwischencodes MSIL verarbeitet. Die CLR basiert auf zwei Bibliotheken: - MSCOREE.DLL - DLL der Laufzeitumgebung - MSCORLIB.DLL - Basistypen des Systems Zusammenfassung Das.NET Konzept hat sich zum Ziel gemacht, eine Laufzeitumgebung zu schaffen, die viele verschiedene Programmiersprachen versteht. Die Programme werden in eine Zwischensprache (MSIL) übersetzt, die dann auf vielen verschiedenen Plattformen laufen kann. So stellt Microsoft sicher, dass ihre neuen.net-produkte nicht nur auf Windows und Intel Rechnern laufen, sondern auch auf vielen anderen. Die Programmierer müssen sich jedoch einem gewissen Standard anpassen, der das Ganze erst möglich macht. Da dieses Konzept noch relativ neu ist, wird sich erst in der Zukunft zeigen, ob sich das Konzept bewährt

19 4.5) Das Smalltalk virtuelle Maschine Modell Smalltalk wurde als erste Programmiersprache rein auf objektorientierter Basis entwickelt. Auch Java verfolgt dieses Konzept. Durch die virtuelle Maschine wird eine enorme Portabilität erreicht. Das heisst, dass Programme, die in Smalltalk geschrieben wurden, auf verschiedenen Plattformen laufen können. Es braucht dazu nur eine Implementation der virtuellen Maschine von Smalltalk auf der jeweiligen Plattform. Der Quellcode eines Programms wird in einem Zwischencode, Bytecode genannt, übersetzt, der dann von der virtuellen Maschine in spezifischen Maschinencode übersetzt wird. Das gleiche Konzept verfolgt auch Java mit seiner virtuellen Maschine, wobei der Bytecode von Java und Smalltalk nicht identisch ist, also anderen Standrads unterliegt. Es gibt jedoch heute Bemühungen, eine virtuelle Maschine für Java und Smalltalk zu realisieren. Wie funktioniert die virtuelle Maschine von Smalltalk? In einem Smalltalk-System unterscheidet man zwei wesentliche Komponenten: Das virtuelle Bild ( virtual image ). Das virtuelle Bild besteht aus allen Objekten, die sich (zur Zeit) im System befinden. Die entsprechende Datei wird Image-File genannt. Die virtuelle Maschine ( virtual machine ). Die virtuelle Maschine ist die Software, die im Verbund mit der Hardware die Systemobjekte ins Leben ruft und sie verwaltet. Die virtuelle Maschine von Smalltalk besteht aus folgenden wesentlichen Elementen: Speicherverwaltungseinheit ( storage manager ) Compiler Interpreter und Primitive Methoden. Der Speichermanager Diese Einheit stellt zusammen mit den Primitiven (Methoden, Unterprogrammen) den grössten Teil der virtuellen Maschine dar. Objekte werden im Speicher des Rechners dynamisch verwaltet. Der Speichermanager ist für die Ausführung zahlreicher Aufgaben zuständig: Erzeugung neuer Objekte Ermittlung der Objektklassen Speichern und Aktivieren von Datenelementen eines Objektes und Durchführung der Speicherbereinigung ( garbage collection ) nicht mehr gebrauchte Objekte werden aus dem System entfernt. Jedes Objekt wird durch einen eindeutigen Zeiger gekennzeichnet, über den es vom Speichermanager angesprochen werden kann. Der Compiler Der Smalltalk-Quellcode wird vom System als String abgespeichert. Der Smalltalk Compiler übersetzt den Quellcode in die Instruktionen einer virtuellen Maschine. Aus dem Smalltalk- Quellcode wird eine Folge von Bytes (Bytecode), die dem Befehlssatz dieser virtuellen Maschine entspricht. Nach der fehlerfreien Compilierung des Quellcodes nimmt das System die neuen Objekte (Methoden, Klassen, Pools,...) in ihr virtuelles Bild auf

20 Die virtuelle Maschine entspricht einer stackorientierten Maschine mit ein paar Hundert Bytecode Operationen. Man unterscheidet fünf wesentliche Befehlsgruppen: Push Bytecodes. Befehle dieser Gruppe legen Objekte auf den Stack Store Bytecodes. Befehle dieser Gruppe speichern das oberste Objekt auf dem Stack als Variablenwert ab Send Bytecodes. Befehle dieser Gruppe senden Botschaften. Die entsprechenden Argumente werden über den Stack verwaltet. Return Bytecodes. Befehle dieser Gruppe legen die Ergebnisse von Methoden auf den Stack. Jump Bytecodes. Befehle dieser Gruppe ermöglichen eine nichtsequentielle Abarbeitung von Bytecodes und lassen sich weiter in bedingte und unbedingte Sprunganweisungen einteilen. Der Interpreter Die vom Compiler erstellten Bytecodes werden vom Interpreter abgearbeitet. Der Interpreter übersetzt diesen Bytecode, gleich wie bei Java, in die spezifische Maschinensprache. Primitive Methoden Ausführung von Methoden durch den Interpreter führt typischerweise zu weiteren Ausführung von weiteren Instruktionen. Diese Vorgehensweise endet erst dann, wenn der Interpreter auf eine Instruktion trifft, die in der Maschinensprache der realen Maschine implementiert ist. Solche Methoden werden als primitive Methoden ( primitive methods ) bezeichnet. In Smalltalk gibt es typischerweise mehr als hundert solcher Methoden die verschiedene Operationen in der Maschinensprache der realen Maschine ausführen. Dazu gehören vor allem diverse numerische Operationen, wie auch Vergleichs- und Bitoperationen, Stack- und I/O- Operationen und gewisse grafische Operationen. Je mehr solche Methoden es in einer Smalltalk-Umgebung gibt, desto leistungsfähiger wird das ganze System. Auf der anderen Seite werden damit die Probleme, die bei der Portierung einer solchen virtuellen Maschine vorkommen, nur umfangreicher. Zusammenfassung Das virtuelle Maschine Prinzip von Smalltalk wurde wie bei Java mit dem Ziel entwickelt, dass Smalltalkprogramme auf verschiedenen Plattformen laufen können (hohe Portabilität). Die virtuelle Maschine von Smalltalk wurde (nicht wie.net) für nur eine Programmiersprache, eben Smalltalk, entwickelt. Smalltalk macht wie Java den Gebrauch von einem Zwischencode, dem Bytecode, um die Portabilität zu ermöglichen. Dieser Bytecode wird dann zur Laufzeit durch den Interpreter in Maschinencode übersetzt und ausgeführt

21 5.) Zusammenfassung Ich wollte in dieser Arbeit die verschiedenen Arten einer virtuellen Maschine aufzeigen. Es gibt viele verschiedene Modelle, eine virtuelle Maschine zu realisieren: Das IBM Modell, das UNIX Betriebssystem, das Java/Smalltalk Modell, das.net Prinzip und viele mehr. Die primäre Charakteristika jeder virtuellen Maschine liegt im Lösen eines bestimmten Problems. Das IBM Modell löst das Problem, dass ein einzelner, grosser Mainframe mehrere Computer mit verschiedenen Betriebssystemen simulieren kann. Ein bemerkenswerter Vorteil im IBM Modell ist das Aufteilen der gleichen Hardware auf verschiedene Programme, indem man die Computerressourcen teilt und die einzelnen Programme komplett voneinander trennt. Das virtuelle Maschine Modell von UNIX löst viele Probleme bei der Computerentwicklung, indem man einen modularen Ansatz gewählt hat, der es ermöglicht, das Ausführen von UNIX Prozessen zu verwalten, sowie diese zu kontrollieren. Der Erfolg des UNIX Betriebssystems beruht zu einem grossen Teil auf der Vielseitigkeit und Skalierbarkeit der UNIX Prozesse. Die UNIX Prozesse können hier als virtuelle Maschine betrachtet werden. Das virtuelle Maschine Modell von Java und Smalltalk widmet sich dem Problem, dass ein Programm auf mehreren Plattformen laufen kann. Die Portabilität zwischen mehreren Plattformen erlaubt es den Programmierern, Programme auf verschiedenen Plattformen laufen zu lassen, ohne diese Programme neu schreiben zu müssen. Der bemerkenswerteste Vorteil ist ein Programm einmal zu schreiben und es dann auf mehreren Betriebssystemen mittels einer virtuellen Maschine laufen zu lassen. Microsoft verfolgte mit ihrem Modell einer virtuellen Maschine, eine Laufzeitumgebung zu erschaffen, die es ermöglicht, Programme auf verschiedenen Plattformen laufen zu lassen. Der Unterschied zu Java/Smalltalk liegt darin, dass.net sich nicht nur auf eine spezielle Programmiersprache konzentriert, sondern die Möglichkeit bietet, Programme in verschiedenen Programmiersprachen zu verarbeiten. So wird eine hohe Portabilität erreicht. Wie man sieht, eignet sich das Konzept einer virtuellen Maschine sehr gut zur Lösung einiger wichtigen Probleme in der Computerwelt. Man kann gespannt sein, was in Zukunft auf diesem Gebiet der Informatik passieren wird

22 6.) Quellen - Einführung in die Informatik; H.-P. Grumm / M. Sommer, 3. Auflage Oldenbourg Verlag - The Java Virtual Machine Specification; Tim Lindholm & Frank Yelin, Addison Wesley Verlag - EDV Grundwissen; Precht, Meier, Tremel, 6.Auflage, Addison Wesley Verlag - Operation System Concepts; Silberschatz, 5. Auflage, Wiley Verlag - Betriebssysteme; Brause, 2.Auflage, Springer Verlag - Diverse Internetseiten: tunes.org/review/vms.html#vms - vm.cfsan.fda.gov/vmcms.html programmiergrundlagen/java01.htm#java01a cust.nol.at/moocow/javabuch.pdf - java.rrzn.uni-hannover.de/tkji/eidp/werkzeuge/vm.html#vm - www11.informatik.tumuenchen.de/lehre/seminare/seminarss01/ausarbeitungen/javaes.pdf java.sun.com/docs/books/vmspec/html/vmspectoc.doc.html Google News Groups jv/haupt/node4.html WS9899/BS/glossar/HTML/node92.html - java.rrzn.uni-hannover.de/tkji/javakurs/jdk/vm.html - ddi.cs.uni-dortmund.de/iml/is/bs/bs_1.html - wwwagr.informatik.uni-kl.de/~maurer/vorlesungst80.html stud4.tuwien.ac.at/~e / JavaVsSmallTalk/node18.html - presentations/vortrag.html programmiersprachen-geschichte.html - Einleitung/EigenschaftenVonJava.html de/teaching/ws0102/lectures/vas/net.pdf - service.de.uu.net/wcc/support/wcc_uinfo/ Virtuelle_Maschine.html archiv.tu-chemnitz.de/pub/1999/ 0032/data/technical.html - bs4u.informatik.fh-augsburg.de/ skript-bs/bs/node37.html