Virtual Machines

25. VIRTUAL MACHINES

Real machines are made of moving material parts and are typically named for the jobs they are designed to do. Lawnmowers, can-openers, and coffee grinders each come in a variety of designs, sometimes operating on different physical principles, but they have in common that the machines with the same name do the same job at some level of description. Maybe some do it better, but it all depends on what the user wants. A homeowner may prefer a slow lawnmower that is quiet; the owner of a cafe may prefer a coffee grinder that adjusts more accurately for the size of the grind at the cost of being harder to operate. Some machines are versatile: by plugging in a different attachment, you can turn a drill into a saw or a sander. Computers are like that, only instead of having a dozen different things they can be made to do, they can do kazillions of different things. And instead of having to plug in a different attachment for each task, you open a different program—a very long string of zeroes and ones—which changes all the necessary internal switches to just the right settings to accomplish the job. Each of these different systems of settings is a different machine—a different virtual machine, a machine “made of instructions,” not gears and bearings, wires and pulleys. In computers, instructions can take the place of gears and pulleys because instead of processing bread dough or paper pulp or steel billets, computers process information, and information can always be translated into binary code, zero and one, the only code the computer can—or needs to—“read.” Those zeroes and ones are shunted by the trillions through the circuits printed on the silicon chips, temporarily opening and closing gates, moving the streams of information to one circuit or another, thereby controlling what happens to it. The hardware’s millions of tiny places that can be in either state 0 or state 1 are the only “moving parts” of the machine, and which machine a computer is at any moment depends on the settings of thousands or millions of little elements.

A virtual machine is what you get when you impose a particular pattern of instructions (more literally, dispositions) on a real machine that has lots of plasticity— interacting parts that can be in many different states. Since a virtual machine does informational work, it can do the same job as a computer whose “moving parts” are state-changes in hardware by making all those state-changes in representations of those moving parts. You can do long division with a pencil on a piece of paper, or if you are really good at long division, you can do it “in your head” by just representing—imagining—the marks on an imaginary page or blackboard. The yield is just as good either way since it’s information: an answer. Imagining making a ham sandwich, in contrast, is a poor substitute for making a ham sandwich if you’re hungry. So good are computers at doing informational work “in their heads” (by representing the machine that does the work) that it can be next to impossible to tell whether the machine you are using and interacting with is a “dedicated,” “hard-wired,” special-purpose information-processing machine or a virtual machine running on a general-purpose chip. For instance, most if not all of the tiny, cheap computer chips that are now embedded in elevators and air-conditioners, your car, your refrigerator, and the remote control for your television set are actually general-purpose computers, capable of executing versions of all the programs you run on your laptop, but doomed to spend their entire lives executing a single relatively simple program (the ignition-control program, the defrosting cycle, etc.) “burned” into a ROM that freezes all their magnificent competence into a single trick or two. This is cheaper than making special-purpose chips designed to do only these simple tasks.

The concept of a virtual machine is one of the most useful imagination-stretchers to come out of computer science, and having proved its worth in that domain, it is ripe for importing to other areas. I am using the term in a somewhat extended sense, so it is worth knowing the narrower technical meaning. Computer scientists Gerald Popek and Robert Goldberg (1974) defined a virtual machine as “an efficient, isolated duplicate of a real machine”—a duplicate made out of . . . instructions. A real machine, call it A, is actual hardware, made of silicon chips and wires and so forth, and a virtual machine is a computer program (running on some other, different real machine, B) that perfectly imitates the A hardware: it may run a bit slower, because it has to compose all of A’s most basic operations out of the basic operations available on its own hardware, B, but it runs all the same programs. If you have a program that was written to run on the A hardware, it should run without a hitch on the B hardware as well when the B hardware is running the virtual machine imitation of A.

This is a remarkably useful trick, and not just because of the apparent thrift it suggests: Say you don’t have a Mac, but have all this valuable software lying around that only runs on Macs. Well, then, write a virtual machine (VM) imitation of a Mac that runs on your PC, and then your PC can run all the Mac software whenever it runs the Mac VM. Your PC will “pretend” it’s a Mac, and the software will be none the wiser! Think of someone who has broken his arm and has it in a plaster cast. The cast severely restricts the movement of his arm, and its weight and shape also call for adjustments in the rest of his bodily movements. Now think of a mime (Marcel Marceau, say) imitating someone with a plaster cast on his arm; if the mime does the trick well, his bodily motions will be restricted in exactly the same ways: he has a virtual cast on his arm—and it will be “almost visible.” A PC imitating a Mac by running a Mac VM should be indistinguishable—to the software running on it, and to the outside observer—from an actual Mac.

At the time of this account, the practical example Dennett emphasizes runs in the other direction: Mac owners using a virtual machine to run Windows software. The extent of compatibility depends on the implementation. Many programs target an operating system rather than a specific hardware design, and an operating system may in turn support several hardware designs. That’s one reason for extending the concept of a virtual machine, to include virtual imitations of operating systems. An operating system is itself a sort of virtual machine, allowing slightly different hardwares to run the same programs, but an operating system is only software; it does not imitate any actual hardware but creates, by stipulation in effect, an imaginary machine that obeys certain rules, accepts certain inputs, and so forth.

The Java Virtual Machine, or JVM, gives another reason for extending the concept: it specifies a software machine rather than imitating a particular physical computer. Dennett illustrates this with the browser applets familiar at the time of his account. These small programs let website visitors solve puzzles, explore maps, play games, and do “serious” computing. A programmer could target the JVM rather than write a separate program for every supported computer. The user still needed a compatible JVM and browser setup. The useful abstraction is the same: the program addresses a common software machine, while its implementation handles the underlying hardware.

In my extended sense of the term, then, almost any computer program can be considered a virtual machine, since it is software—a systematic list of instructions—that, when it runs, turns a general-purpose computer into a special-purpose machine that could have been designed and wired up as hardware. One of Alan Turing’s most brilliant contributions to science—indeed to human civilization since mid-twentieth century—is the idea of a “Universal” computer (what we call today a Universal Turing machine), which can be turned into any other clearly designed computer simply by installing and running a program on it! (Dennett develops this idea in chapter 24 of his book.) In principle, sufficiently capable hardware can carry out any computation described by a suitable program, subject to memory and time limits. Ever since Turing’s time, we’ve had the remarkable idea that you can take some complicated hunk of stuff—hardware—with lots of plasticity—adjustable “memory” boxes or registers—and put a set of instructions in those memory boxes, which, when executed, will turn your hunk of stuff into whatever computer you can clearly imagine.

A basic Turing machine executes one instruction at a time and moves to the next instruction. The idea can be generalized to “parallel” computers that execute many (millions of) instructions at one time. A register is any place in the hardware that can hold itself in one state or another (like the zero state and the one state of the bits in your computer, but not necessarily restricted to two different states) until something tells it to change its state. A system of registers with the necessary elementary operations on the basis of those states (such as changing a register from one state to another, or using the state of a register to determine what operation to do next) can have its registers set in such a way as to “compute a function” or “run a program.” So any such hardware can run a virtual machine designed to exploit these basic steps. And a trick that can be done once can be done two or three or more times, implementing virtual machines in virtual machines in virtual machines in . . . hardware.

Consider a chess-playing program written in Common Lisp (a high-level computer language) running on Windows 7 (an operating system) running on a PC. This is a PC pretending to be a Windows machine pretending to be a Lisp machine pretending to be a chess-playing machine. If we look at the details of the program at the highest level, they will be more or less comprehensible to a computer-savvy, chess-savvy observer (“Aha! This subroutine generates all the legal responses to moving the bishop and then calls the evaluation subroutine which . . .”). In contrast, looking at the actual machine code of the same program, the strings of zeroes and ones that are fed into the hardware instruction register, is a good way to go crazy or blind, so we wisely focus our attention on the higher levels. At each level, we can see the woods in spite of all the trees because the lower-level details are conveniently invisible. The parallel between the cascade of virtual machines on a computer and the cascade of homunculi in homuncular functionalism about the mind is no mere coincidence. It is the spectacular success of virtual machines in helping us create and comprehend material implementations of hitherto mind-boggling tasks (making airline reservations, playing chess, predicting the weather, taking dictation, etc.) that inspires the hope that we can pull off a similar—only similar—stunt when we reverse engineer the brain.

Perhaps, then, the similarities between human brains whose owners speak French, in spite of all the anatomical differences observable, are best described at the virtual-machine level: all of the French-speakers have one version or another of the FVM, the French Virtual Machine, a system made of interlocking dispositions or microhabits stored, somehow, in the brains’ billions of registers. Brains of English-speakers will be distinguished by a similar system of reliable patterns, the EVM. If you say to a French-speaker, “Donnez-moi le sel, s’il vous plait,” the FVM will reliably control the same behavior you elicit from an English-speaker by feeding the EVM in her brain the input “Please pass me the salt.” Now, how do we build an FVM or EVM that will run in a brain?

We don’t yet know how to describe such different levels in the activities of brains of people playing chess or speaking French.1 No doubt there will be nothing like the precise mappings that have enabled computer programmers to design their inventions at the highest levels with full confidence that a running program will emerge from the compiler (a program that takes the high-level instructions and translates them into code that can run on the hardware). But we do now have an important proof of concept: we know at least one way to make sense of the high-level competences of a machine with trillions of moving parts—without invoking any wonder tissue.