virtual+machine

[|Virtual machine][|From Wikipedia, the free encyclopedia]

A **virtual machine** (**VM**) is a "completely isolated guest operating system installation within a normal host operating system".[1home] Modern virtual machines are implemented with either software emulation or hardware virtualization or (in most cases) both together. hide]
 * ==Contents==
 * 1 VM Definitions
 * 1.1 System virtual machines
 * 1.2 Process virtual machines
 * 2 Techniques
 * 2.1 Emulation of the underlying raw hardware (native execution)
 * 2.2 Emulation of a non-native system
 * 2.3 Operating system-level virtualization
 * 3 List of hardware with virtual machine support
 * 4 List of virtual machine software
 * 4.1 Extended descriptions of selected virtualization software
 * 5 See also
 * 6 References
 * 7 Further reading
 * 8 External links ||

VM Definitions
A virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. Virtual machines are separated into two major categories, based on their use and degree of correspondence to any real machine. A system virtual machine provides a complete system platform which supports the execution of a complete operating system (OS). In contrast, a process virtual machine is designed to run a single program, which means that it supports a single process. An essential characteristic of a virtual machine is that the software running inside is limited to the resources and abstractions provided by the virtual machine—it cannot break out of its virtual environment. A virtual machine was originally defined by Popek and Goldberg as "an efficient, isolated duplicate of a real machine". Current use includes virtual machines which have no direct correspondence to any real hardware.[2home]

edit] System virtual machines
See also: Hardware virtualization and Comparison of platform virtual machines System virtual machine advantages: The main disadvantages of VMs are: Multiple VMs each running their own operating system (called guest operating system) are frequently used in server consolidation, where different services that used to run on individual machines to avoid interference are instead run in separate VMs on the same physical machine. The desire to run multiple operating systems was the original motivation for virtual machines, as it allowed time-sharing a single computer between several single-tasking Operation Systems. In some respects, a system virtual machine can be considered a generalization of the concept of virtual memory that historically preceded it. IBM's CP/CMS, the first systems to allow full virtualization, implemented time sharing by providing each user with a single-user operating system, the CMS. Unlike virtual memory, a system virtual machine allowed the user to use privileged instructions in their code. This approach had certain advantages, for instance it allowed users to add input/output devices not allowed by the standard system.[4home] The guest OSes do not have to be compliant with the hardware making it possible to run different OSes on the same computer (e.g., Microsoft Windows and Linux, or older versions of an OS to support software that has not yet been ported to the latest version). The use of virtual machines to support different guest OSes is becoming popular in embedded systems; a typical use is to support a real-time operating system at the same time as a high-level OS such as Linux or Windows. Another use is to sandbox an OS that is not trusted, possibly because it is a system under development. Virtual machines have other advantages for OS development, including better debugging access and faster reboots.[5home]
 * multiple OS environments can co-exist on the same computer, in strong isolation from each other
 * the virtual machine can provide an instruction set architecture (ISA) that is somewhat different from that of the real machine
 * application provisioning, maintenance, high availability and disaster recovery[3home]
 * a virtual machine is less efficient than a real machine when it accesses the hardware indirectly
 * when multiple VMs are concurrently running on the same physical host, each VM may exhibit a varying and unstable performance (Speed of Execution, and not results), which highly depends on the workload imposed on the system by other VMs, unless proper techniques are used for temporal isolation among virtual machines.

Process virtual machines
See also: Application virtualization, Run-time system, and Comparison of application virtual machines A process VM, sometimes called an //application virtual machine//, runs as a normal application inside a host OS and supports a single process. It is created when that process is started and destroyed when it exits. Its purpose is to provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system, and allows a program to execute in the same way on any platform. A process VM provides a high-level abstraction — that of a high-level programming language (compared to the low-level ISA abstraction of the system VM). Process VMs are implemented using an interpreter; performance comparable to compiled programming languages is achieved by the use of just-in-time compilation. This type of VM has become popular with the Java programming language, which is implemented using the Java virtual machine. Other examples include the Parrot virtual machine, which serves as an abstraction layer for several interpreted languages, and the .NET Framework, which runs on a VM called the Common Language Runtime. A special case of process VMs are systems that abstract over the communication mechanisms of a (potentially heterogeneous) computer cluster. Such a VM does not consist of a single process, but one process per physical machine in the cluster. They are designed to ease the task of programming parallel applications by letting the programmer focus on algorithms rather than the communication mechanisms provided by the interconnect and the OS. They do not hide the fact that communication takes place, and as such do not attempt to present the cluster as a single parallel machine. Unlike other process VMs, these systems do not provide a specific programming language, but are embedded in an existing language; typically such a system provides bindings for several languages (e.g., C and FORTRAN). Examples are PVM (Parallel Virtual Machine) and MPI (Message Passing Interface). They are not strictly virtual machines, as the applications running on top still have access to all OS services, and are therefore not confined to the system model provided by the "VM".

[|Comparison of application virtual machines][|From Wikipedia, the free encyclopedia]

This article lists some software virtual machines that are typically used for allowing application bytecode to be portably run on many different computer architectures and operating systems. The application is usually run on the computer using an interpreter or just-in-time compilation. There are often many implementations of a given virtual machine, each covering a different functionality footprint. hide]
 * ==Contents==
 * 1 Comparison of virtual machines
 * 2 List of application virtual machine implementations
 * 3 References
 * 4 See also
 * 5 External links ||

Comparison of virtual machines
The table here summarizes elements for which the virtual machine designs intended to be efficient, not the list of capabilities present in any implementation. Virtual machine instructions process data in local variables using a main **model of computation**, typically that of a stack machine, register machine, or random access machine often called the memory machine. Use of these three techniques is motivated by different tradeoffs in virtual machines vs physical machines, such as ease of interpretation, compilation, and verifiability for security. An **interpreter** allows programs made of virtual instructions to be loaded and immediately run without a potentially costly compilation into native machine instructions. Any virtual machine which can be run can be interpreted, so the column designation here refers to whether the design includes provisions for efficient interpretation (for common usage). Just-in-time compilation or **JIT**, refers to a method of compiling to native instructions at the latest possible time, usually immediately before or during the running of the program. The challenge of JIT is more one of implementation than of virtual machine design, however, modern designs have begun to make considerations to help efficiency. The simplest JIT techniques simply perform compilation to a code-fragment similar to an offline compiler. However, more complicated techniques are often employed, which specialize compiled code-fragments to parameters that are known only at runtime (see Adaptive optimization).
 * ~ Virtual machine ||~ Machine model ||~ Memory management ||~ Code security ||~ Interpreter ||~ JIT ||~ Precompilation ||~ Shared libraries ||~ Common Language Object Model ||~ Dynamic typing ||
 * ~ CLR || stack || automatic or manual ||= Yes ||= No ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes ||
 * ~ Dis (Inferno) || register || automatic ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes ||= No ||= No ||
 * ~ DotGNU Portable.NET || stack || automatic or manual ||= No ||= No ||= Yes ||= Yes ||= Yes ||= Yes ||= No ||
 * ~ JVM || stack || automatic ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes[1home] ||
 * ~ JikesRVM || stack || automatic ||= No ||= No ||= Yes ||= No || //**?**// ||= No ||= No ||
 * ~ LLVM || register || manual ||= No ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes ||= No ||
 * ~ Mono || stack || automatic or manual ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes ||= Yes ||
 * ~ Parrot || register || automatic ||= No ||= Yes ||= No[2home] ||= Yes ||= Yes ||= Yes ||= Yes ||
 * ~ Dalvik || register || automatic ||= Yes ||= Yes ||= Yes || //**?**// || //**?**// ||= No ||= No ||
 * ~ libJIT || stack || manual ||= No ||= No ||= Yes ||= No ||= No || //**?**// ||= No ||
 * ~ Squeak || stack || automatic ||= No ||= Yes ||= Yes ||= source to bytecode ||= Yes ||= No ||= Yes ||
 * Memory management** in these portable virtual machines is addressed at a higher level of abstraction than in physical machines. Some virtual machines, such as the popular JVM, are involved with addresses in such a way as to require safe automatic memory management by allowing the virtual machine to trace pointer references, and disallow machine instructions from manually constructing pointers to memory. Other virtual machines, such as LLVM, are more like traditional physical machines, allowing direct use and manipulation of pointers. CIL offers a hybrid in between, offering both controlled use of memory (like the JVM, which allows safe automatic memory management), while also offering an 'unsafe' mode that allows direct manipulation of pointers in ways that can violate type boundaries and permission.
 * Code security** generally refers to the ability of the portable virtual machine to run code while only offering it a prescribed set of capabilities. For example, the virtual machine might only allow the code access to a certain set of functions or data. The same controls over pointers which make automatic memory management possible and allow the virtual machine to ensure typesafe data access are used to assure that a code fragment is only allowed to certain elements of memory and cannot sidestep the virtual machine itself. Other security mechanisms are then layered on top as code verifiers, stack verifiers, and other techniques.
 * Precompiling** refers to the more classical technique of using an offline compiler to generate a set of native instructions which do not change during the runtime of the program. Because aggressive compilation and optimization can take time, a precompiled program may launch faster than one which relies on JIT alone for execution. JVM implementations have mitigated this startup cost by using interpretation initially to speed launch times, until native code-fragments can be generated through JIT.
 * Shared libraries** are a facility to reuse segments of native code across multiple running programs. In modern operating systems, this generally means using virtual memory to share the memory pages containing a shared library across different processes which are protected from each other via memory protection. It is interesting that aggressive JIT techniques such as adaptive optimization often produce code-fragments unsuitable for sharing across processes or successive runs of the program, requiring a tradeoff be made between the efficiencies of precompiled and shared code and the advantages of adaptively specialized code. For example, several design provisions of CIL are present to allow for efficient shared libraries, possibly at the cost of more specialized JIT code. The JVM implementation on Mac OS X uses a Java Shared Archive ([|apple docs]) to provide some of the benefits of shared libraries.

List of application virtual machine implementations
In addition to the portable virtual machines described above, virtual machines are often used as an execution model for individual scripting languages, usually by an interpreter. This table lists specific virtual machine implementations, both of the above portable virtual machines, and of scripting language virtual machines.
 * ~ Virtual machine ||~ Languages ||~ Comments ||~ Interpreter ||~ JIT ||~ Implementation Language ||~ SLoC ||
 * ~ Adobe Flash Player (aka Tamarin) || ActionScript, SWF (file format) || interactive web authoring tool. bytecode is named "ActionScript Byte Code (.abc)" ||= Yes ||= Yes || C++ || 135k (initially released) ||
 * ~ BEAM || Erlang, Reia, Lisp Flavoured Erlang, [|Elixir] || There exists a native-code compiler, HiPE. ||= Yes ||= No || C || 247k ||
 * ~ Clipper p-code || Clipper, Harbour || plankton, HVM ||= Yes ||= No || C ||  ||
 * ~ Dis (Inferno) || Limbo || [|Dis Virtual Machine Specification] ||= Yes ||= Yes || C || 15k + 2850 per JIT arch + 500 per host OS ||
 * ~ DotGNU/Portable.NET || CLI languages including: C# || Clone of Common Language Runtime ||= No ||= Yes || C, C# ||  ||
 * ~ Forth || Forth || Features are simplified, usually include assembler, compiler, text-level and binary-level interpreters, sometimes editor, debugger and OS. Compilation speeds are >20 SKLOC/S and behave much like JIT. ||= Yes ||= No || Forth, Forth Assembler || 2.8K to 5.6K; advanced, professional implementations are smaller. ||
 * ~ Glulx || Glulx, Z-code ||  ||   ||   ||   ||   ||
 * ~ Icon || Icon ||  ||   ||   ||   ||   ||
 * ~ JVM || Java, Jython, Groovy, JRuby, C, C++, Clojure, Scala and [|several others] || [|Reference implementation] by Sun ; OpenJDK: code under GPL ; IcedTea: code and tools under GPL ||= Yes ||= Yes || JDK, OpenJDK & IcedTea with regular JIT : Java, C, ASM ; IcedTea with the "Zero" JIT : Java, C || JVM is around 6500k lines; TCK is 80k tests and around 1000k lines ||
 * ~ LLVM || C, C++, Objective-C, Ada, and Fortran || MSIL, C and C++ output are supported. ActionScript Byte Code output is supported by Adobe Alchemy. bytecode is named "LLVM Bytecode (.bc)". assembly is named "LLVM Assembly Language (*.ll)". ||= Yes ||= Yes || C++ || 811k [3home] ||
 * ~ Lua || Lua ||  ||= Yes || [|LuaJIT] || C || 13k + 7k LuaJIT ||
 * ~ MMIX || MMIXAL ||  ||   ||   ||   ||   ||
 * ~ Mono || CLI languages including: C#, VB.NET, IronPython, IronRuby, and others || clone of Common Language Runtime. ||= Yes ||= Yes || C#, C || 2332k ||
 * ~ Oz || Oz, Alice ||  ||   ||   ||   ||   ||
 * ~ NekoVM || currently Neko and haXe ||  ||= Yes || x86 only || C || 46k ||
 * ~ O-code machine || BCPL ||  ||   ||   ||   ||   ||
 * ~ p-code machine || Pascal || UCSD Pascal, widespread in late 70s including Apple II ||  ||   ||   ||   ||
 * ~ Parrot || Perl (6 & 5), NQP-rx, PIR, PASM, PBC, BASIC, bc, C, ECMAScript, Lisp, Lua, m4, Tcl, WMLScript, XML, and others ||  ||= Yes ||= Yes || C, Perl || 111k C, 240k Perl ||
 * ~ Perl virtual machine || Perl || op-code tree walker ||= Yes ||= No || C, Perl || 175k C, 9k Perl ||
 * ~ CPython || Python ||  ||= Yes || Psyco || C || 387k C, 368k Python, 10k ASM, 31k Psyco ||
 * ~ PyPy || Python || Self-hosting implementation of Python, next generation of Psyco ||= Yes ||= Yes || Python ||  ||
 * ~ Rubinius || Ruby || Virtual machine for another Ruby implementation ||= Yes ||= Yes || C++, Ruby ||  ||
 * ~ Silverlight || C#, VB.NET || A Micro-version of Microsoft .NET Framework to allow applications run sandboxed inside browser ||= Yes ||= Yes || C++ || 7MB (initially released) ||
 * ~ SEAM || Alice ||  ||   ||   ||   ||   ||
 * ~ ScummVM || Scumm || Computer game engine ||  ||   ||   ||   ||
 * ~ SECD || ISWIM, Lispkit Lisp ||  ||   ||   ||   ||   ||
 * ~ Squirrel || Squirrel ||  ||= Yes || Squirrel_JIT || C++ || 12k ||
 * ~ Smalltalk || Smalltalk ||  ||   ||   ||   ||   ||
 * ~ SQLite || SQLite opcodes || Virtual database engine ||  ||   ||   ||   ||
 * ~ Squeak || Squeak Smalltalk || Self hosting implementation of Squeak virtual machine. Rich multi-media support. ||= Yes ||= Cog[|[1]] & Exupery || Smalltalk/[|Slang] || 110k Smalltalk, ~300K C ||
 * ~ TaoGroup VP/VP2 || C, Java || Proprietary embedded VM ||  ||   ||   ||   ||
 * ~ TraceMonkey || JavaScript || Based on Tamarin ||= No ||= Yes || C++ || 173k ||
 * ~ Translator Engine[//citation needed//] || Flat File Tables/Global C++ variable declarations || IDE, programming by demonstration ||  ||   ||   ||   ||
 * ~ TrueType || TrueType || Font rendering engine ||= Yes ||= No || C (typically) ||  ||
 * ~ Valgrind || x86/x86-64 binaries || Checking of memory accesses and leaks under Linux ||  ||   || C || 467k [4home] ||
 * ~ VisualWorks || Smalltalk ||  ||= No ||= Yes || C ||   ||
 * ~ [|VMKit] ||  || JVM and CLI virtual machine based on LLVM. ||= No ||= Yes ||   ||   ||
 * ~ Vx32 virtual machine ||  || Application-level virtualization for native code ||   ||   ||   ||   ||
 * ~ Waba ||  || Virtual machine for small devices, similar to Java ||   ||   ||   ||   ||
 * ~ Yet Another Ruby VM (YARV) || Ruby || Virtual machine of the reference implementation for Ruby 1.9 and newer versions ||= Yes ||= Yes || C ||  ||
 * ~ Z-machine || Z-Code ||  ||   ||   ||   ||   ||
 * ~ Zend Engine || PHP ||  ||= Yes ||= No || C || 75k ||
 * ~ libJIT Library for Just-In-Time compilation || Common Intermediate Language Java bytecode Domain-specific programming language || Virtual machine is used in Portable.NET Just-In-Time compiler, ILDJIT, HornetsEye ||= Yes ||= Yes || C, ia32, arm, amd64, alpha, low-level CPU architecture specific machine code ||  ||