Riggs 1

The Virtual Machine

Submitted by: Matthew Riggs

Submitted to: Dr. E. Durant

Date Submitted: 1 February 2006

Riggs 2

Table of Contents

Introduction........................................................................................................................3

The Beginnings of the IBM Virtual Machine...............................................................4

The Beginning of the Java Virtual Machine.................................................................5

The Portable Virtual Machine: The Java Virtual Machine.........................................7

The Multiple Workstation System: The VMware Virtual Machine..........................9

Conclusion.........................................................................................................................12

Appendix of Illustrations...................................................................................................14

References..........................................................................................................................15

Riggs 3

Introduction

The term ‘virtual machine’ represents multiple products, each developed for

different reasons and during different times. The aspect that ties these different

technologies together under one title is the same goal: to seamlessly emulate a

completely different machine or function [4]. There are two completely different

technologies under the label of ‘virtual machine’: the IBM model, and the Java

model. Both of these models were developed for a different reason and at a

different time.

Figure 1: Some technologies under the virtual machine. Each with a different use

and method of achieving them, the general theme can be seen here as the

emulation of something that is not present. The IBM model shows each client a

whole and dedicated system, the Java model shows the code a Java operating

system, and the OSI model shows a series of drives where physically only one

drive exists.

Riggs 4

The Java virtual machine enables Java code to run on nearly any machine. The

Java code only sees a completely compatible operating system to run on; the Java

platform handles the Java code to host OS translation. The IBM virtual machine

concentrates on a different form of emulation, allowing multiple users to access

their own ‘desktop’, a secure duplicate of other desktops running on the virtual

machine. These technologies are still developing, and have drawbacks compared

to other alternatives. An IBM model has a much higher resource demand than a

stand-alone system, and this can easily outweigh the gain of its ability to satisfy

multiple users. The Java virtual machine does not solve all of its portability

demands, losing to the tried-and-true method of recoding based on the targeted

platform. Virtual machines are continuously changing, and the ideas behind them

are being applied to a wide variety of fields, accomplishing a multitude of tasks

less expensively and more conveniently.

The Beginnings of the IBM Virtual Machine

The first computer to be classified as a virtual machine was built on IBM’s S/360

model 67 in 1967 [5], [6]. This S/360 model was an important step for IBM, who

was beginning to lag behind the academic community because of IBM’s strongly

held belief that faster batch processing was the correct technology to pursue [5].

MIT, who had been developing ‘time-sharing’ or multiprocessing, had begun to

turn from its nearly exclusive partnership with IBM, as IBM released the first

S/360 model without the ability to perform time-sharing [5], [6]. The S/360

model 67 was the platform on which the CP-40 ran, the first incarnation of the

virtual machine (among other important technologies). The CP-40 was developed

Riggs 5

as a research project by IBM’s Cambridge laboratory, because after the S/360/67

was built and being produced, the time-sharing aspect was being developed as

TSS in IBM’s New York State location [5], leaving the Cambridge lab to work

abstractly. The virtual machine’s (originally called pseudo machine [5]) purpose

was to provide security to each of the users of the CP-40. That there were

multiple users of the same system was an innovation in itself, although the

number of users was limited to 14, and the memory usage of each limited to

256 k [5]. Before the CP-40, a time-sharing system would have a virtual

platform, which appeared to the user to be more powerful than the system

actually was [6].

The CP-40, on the other hand, gave each user their own virtual S/360, with their

‘own’ drives and processing ability. This was accomplished using P-disks

(seamlessly managed partitions of a single physical drive), which is now

considered to be an offshoot of the virtual machines idea, called the ‘OSI’ model.

One of the most important aspects of the CP-40’s virtual machine function was

that it showed how “elegantly a virtual machine system could be built, with

really very minor hardware changes and not much software [6]”. The SP-40’s

virtual machine implementation was fully realized in the Cambridge Monitor

System, or CMS, which allowed the SP-40’s users to operate as separate and

secure S/360 platforms.

Riggs 6

The Beginning of the Java Virtual Machine

The Java Virtual Machine (JVM) has little to do with the original virtual

machine, except in the essence of the end result. The idea of the Java

programming language (the basis on which the JVM works) started in 1970 in the

mind of Bill Joy, co-founder of Sun. That idea did not come to fruition until the

1990s, when Sun began to looking into the focused development of its products

and the portability that would be required [4]. The language which the JVM runs

is Java, which was once Oak, an offshoot of C++ written by James Gosling

during the time when Bill Joy was publishing his ideas for the JVM in the paper

Further, became the basis for the JVM to run because of its simplified and

streamlined designed comparative to C++ or C. Java supplied Sun with what it

was searching for: concise code.

This was only a part of the equation to attain easy portability, as the Java code

was still platform specific (the Java code would still require OS tailoring, as in

Windows or Linux or Mac, all possessing different instruction sets). The JVM

was the end result of this need for a platform independent design. Small and

efficient, the JVM was designed as to be a virtual machine in that it provides

another layer of coding and decoding between the processor and the user. The

JVM provides two things to the Java code developed by Sun: portability, as the

JVM’s purpose is to translate the Java compiled code into platform-usable

instructions, and programming simplicity, as the code remains basic and

unchanged regardless of the platform.

Riggs 7

The Portable Virtual Machine: The Java Virtual Machine

The Java Virtual Machine has one focus: to make Java programs (and Sun’s

products) more portable. This is accomplished in a way that emulates the very

first computer systems: a virtual machine image is presented to both sides of the

computer application equation (F1) [8].

Figure 2. The JVM ‘layer’ approach. This shows how the data flows, and what

both the host operating system and the application see. The application sees a

compatible Java operating system, and the operating sees a flow of usable

instructions.

The code sees a perfectly compatible Java machine that is capable of handling

the compiled code without translational or operational errors. The platform the

code is running on also sees what it wants to see, instructions that are tailored to

the platform’s operating system so there are no misunderstandings, and no errors

to handle. The end result is extremely portable code written in Java [5]. The

Riggs 8

VMSpec, provided by Sun for use with its JVM, takes an in-depth, item-by-item

approach to explaining the operation of the Java Virtual Machine [9]. Java (the

programming language) is usually compiled into a class file, which provides the

JVM with generic coding information. “Compiled code to be executed by the

Java virtual machine is represented using a hardware- and operating system-

independent binary format, typically (but not necessarily) stored in a file, known

as the class file format [9].” The class file is simply a list of bytecodes compiled

from the original Java programming language description. The JVM then takes

these bytecodes and translates them into basic instructions. At this point the JVM

is looking at the assembly code, and similar to MIPS architectural equations, it

follows the very basic format of , so on. The JVM

knows to expect these operands based on the opcode given [8]. Although this

may seem unsafe to depend on the opcode to determine the number or existence

of operands, the Java code has already been compiled, and as such will not cause

a real-time fault as long as the content of the basic operations is sound.

At this point, the JVM can translate the basic instructions into short commands to

the operating system. From a programming flow point of view, the Java language

is set up so that the assembling of the Java code is done dynamically, at the

platform the code is to be executed on, allowing the JVM, in this case the

assembler, to tailor the assembled code to suit the operating system and there-by

create compatible code.

Riggs 9

To be appealing to consumers, the JVM needed to be compact, and this was

achieved at the cost of a few compatibility choices. An example of a noticeable

decision to preserve the brevity of the JVM (and the compiled Java code) is the

decision to use one byte long opcode [9]. “The decision to limit the Java virtual

machine opcode to a byte and to forgo data alignment within compiled code

reflects a conscious bias in favor of compactness, possibly at the cost of some

performance in naive implementations [9].”

The Multiple Workstation System: The VMware Virtual Machine

IBM’s Cambridge office developed the virtual machine, opening up a new world

of computing solutions that are still entirely viable today. Cambridge’s invention

also allowed IBM to diversify itself, an opportunity which IBM took and still

uses to its advantage. IBM moved away from the workstation side of the virtual

machine and began to concentrate on virtual servers, which were a higher-end

business commodity, not so subject to public knowledge or popularity. The

‘workstation’ virtual machine did not stop there, however, and several companies

took up the technology, adding different tweaks to it along the way.

VMware developed a virtual machine platform that isn’t standalone like the IBM

VM. The VMware model runs as an application on the host OS (called the hosted

virtual machine model [10]), allowing a less computer savvy user to create

virtual machines easily. This OS-based operation is achieved using a series of

protections that is in common use in operating systems and is based closely on

Riggs 10

the Intel IA32 architecture, which provides 4 levels of protection (see Figure 3)

[10].

Figure 3. This a protection scheme used by Intel, and is useful to explain how the

VMware virtual machine integrates itself so that it can successfully run multiple

clients.

A normal operating system will have the most sensitive operations available to it

in Level 0, such as interrupt handling [10]. When VMware is applied to this

system, it must have access to all levels of the protection scheme. This is

accomplished by 3 distinct parts, the VMware driver, the VMware monitor, and

the VMware application. The VMware driver and monitor sit in Level 0,

allowing unrestricted access to instructions. The VMware application sits in

Level 1, and acts as a go-between for the operating system, which sees it as just

another application, without any special privileges. Using this underlying

framework, virtual machines can finally be created. There is an obvious

Riggs 11

drawback to this system, and it becomes evident that the host OS approach can

greatly affect performance.

The VMware driver can access interrupt handling and other sensitive operations,

however it is unable to perform scheduling, which means that any of the client

virtual machines are not only playing second fiddle to the host OS’s concerns,

they could be interrupted during a critical section, and the OS might not realize.

This issue becomes apparent in today’s virtual machine systems during periods

of heavy I/O reliance, as the I/O system becomes a bottleneck. The VM monitor

can use the OSI model to partition the host workstation’s resources, but the I/O

waits cannot be partitioned or ignored. The worst bogging experience is during

network operations; however VMware has come to handle this, cutting down on

the performance hit the clients experience during network communications. The

VM application ‘reads’ what I/O operations each client is initiating, and

summarizes them, cutting down on the time each client requires the I/O devices.

This sounds like it would cause packet and data loss, however, as redundancy is

reduced and status checks are ignored, the VM application keeps tabs, and if the

client begins to falter, it can restore the original request for I/O use, so that the

client users are still able to complete tasks.

Another potential drawback is the protection and security aspect of the client

virtual machines, in respect to each other as well as to outside influences. This

problem was, even in the IBM CP-40’s day, handled with great care. With the

Riggs 12

VMware system, interrupts are utilized to outright stop a client from tampering

with another. The VMware monitor runs an algorithm to determine the intent of

the instruction (flagged by the driver as potentially sensitive), and either allows a

harmless one, or does not run the instruction. This approach is brute force and

unforgiving, any application that a client user is running will likely find it’s way

into error because of the VMware driver’s actions. The problem with this is that

the algorithm used to determine the intent of the client’s instruction has to be

inscrutable, to the point that it needs to understand all of the possible ways a

client to client security breach can occur. Computer security has grown in recent

years, and has become an ever changing industry. VMware (and IBM with their

virtual server application) has come to develop a kit or packet of algorithms,

which have seen updates every time a product update is produced.

ConclusionVirtual machines, ever since their invention, have come to be a widely sought-

after alternative to the workstation or single-server route. Drawbacks, as with

every choice between competing options has, still plague parts of the virtual

machine technology. As the processes and methods used to provide the

functionality of the virtual machine is refined and reworked, a sudden and

advance change in the way computers are used could occur.

An optimist could envision consumers buying or renting a share in a virtual

machine stored miles away, saving the consumer the cost of the hardware and

repair. An entrepreneur could see virtual machines being used to monitor patients

Riggs 13

in hospitals, the data waiting patiently, stored in a system until that patient was

again hooked into the system. Any who investigates the market will see the vast

potentials which are available to the virtual machine industry, and seem about

ready to appear. As it is now, the virtual machines are a smart and generally safe

alternative to the stand-alone systems popular today as personal computers. Their

value in today’s market is undeniable.

Riggs 14

Appendix of Illustrations

Figure 1…………………………………………………………………page 3

Figure 2…………………………………………………………………page 7

Figure 3…………………………………………………………………page 10

Riggs 15

References

Baratz, Adam. “Virtual Machine shootout: VMware vs. Virtual PC.” Ars Technica. 8 August 2004. arstechnica.com. 9 January 2006 <http://arstechnica.com/reviews/apps/vm.ars/1> [1]

Lindholm, Tim and Frank Yellin. “The Java Virtual Machine Specification: Second Edition.” Sun Microsystems. 1999. Sun Microsystems. 9 January 2006 <http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html> [2]

Haldar, Vivek, et al. Semantic Remote Attestation-A Directed Approach to Trusted Computing. usenix.org. 2004. Usenix. 9 January 2006 <http://www.usenix.org/events/vm04/tech/haldar/haldar.pdf> [3]

Kohlbrenner, Erik, et al. “The History of Virtual Machines.” Hyperlearning Center. 1999. cne.gmu.edu. 9 January 2006<http://www.cne.gmu.edu/itcore/virtualmachine/index.htm> [4]

Varian, Melinda. VM and the VM community: Past, Present, and Future. Princeton University. 1997. princeton.edu. 10 January 2006 <http://www.princeton.edu/~melinda/ 25paper.pdf> [5]

Van Vleck, Tom. “The IBM 360/76 and CP/CMS.” Multicians. 30 December 2005. multicians.org. 10 January 2006 <http://www.multicians.org/thvv/360-67.html> [6]

Venners, Bill. “The Lean, Mean, Virtual Machine.” JavaWorld. 2005. javaworld.com. 22 January 2006 <http://www.javaworld.com/javaworld/jw-06-1996/jw-06-vm.html> [7]

“Virtual Machines and VMware, Part I” Ziff Davis, Inc. 2005. extremetech.com. 28 January 2006 <http://www.extremetech.com/article2/0,1697,1156610,00.asp> [8]