- Comparison of application virtual machines
-
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.
Contents
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 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[1] 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 No 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 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.
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.
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).
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 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++ 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 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 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 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 References
See also
- Application virtualization
- Language binding
- Foreign function interface
- Calling convention
- Name mangling
- Application programming interface (API)
- Application Binary Interface (ABI)
- Comparison of platform virtual machines
External links
Categories:- Software comparisons
- Virtualization software
- Virtual machines
Wikimedia Foundation. 2010.
