Comparison of application virtualization software

Application virtualization software refers to both application virtual machines and software responsible for implementing them. Application virtual machines are typically used to allow application bytecode to run portably on many different computer architectures and operating systems. The application is usually run on the computer using an interpreter or just-in-time compilation (JIT). There are often several implementations of a given virtual machine, each covering a different set of functions.

Comparison of virtual machines

JavaScript machines not included. See List of ECMAScript engines to find them.

The table here summarizes elements for which the virtual machine designs are intended to be efficient, not the list of abilities present in any implementation.

Virtual machine	Machine model	Memory management	Code security	Interpreter	JIT	AOT	Shared libraries	Common Language Object Model	Dynamic typing
Android Runtime (ART)	register	automatic	Yes	Yes	Yes	Yes	?	Yes	Yes
Common Language Runtime (CLR)	stack	automatic or manual	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Dis (Inferno)	register	automatic	Yes	Yes	Yes	Yes	Yes	Yes	Yes
DotGNU Portable.NET	stack	automatic or manual	Yes	Yes	Yes	Yes	Yes	Yes	No
Java virtual machine (JVM)	stack	automatic	Yes	Yes	Yes	Yes	Yes	Yes	Yes
JikesRVM	stack	automatic	Yes	Yes	Yes	Yes	?	Yes	Yes
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	Yes	Yes	Yes	Yes
Dalvik	register	automatic	Yes	Yes	Yes	No	?	No	No
Squeak	stack	automatic	No	Yes	Yes	No	Yes	No	Yes
BEAM (Erlang)	register	automatic	?	Yes	Yes	Yes	Yes	Yes	Yes
MoarVM	register	automatic	?	Yes	Yes	Yes	Yes	Yes	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 methods is motivated by different tradeoffs in virtual machines vs physical machines, such as ease of interpreting, compiling, and verifying 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 Java virtual machines (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. Common Intermediate Language (CIL) offers a hybrid in between, allowing both controlled use of memory (like the JVM, which allows safe automatic memory management), while also allowing an 'unsafe' mode that allows direct pointer manipulation 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 offering it only a prescribed set of abilities. 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 bypass the virtual machine itself. Other security mechanisms are then layered on top as code verifiers, stack verifiers, and other methods.

An interpreter allows programs made of virtual instructions to be loaded and run immediately without a potentially costly compile 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 interpreting (for common usage).

Just-in-time compilation (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 methods simply compile to a code fragment similar to an offline compiler. However, more complex methods are often employed, which specialize compiled code fragments to parameters known only at runtime (see Adaptive optimization).

Ahead-of-time compilation (AOT) refers to the more classic method of using a precompiler to generate a set of native instructions which do not change during the runtime of the program. Because aggressive compiling and optimizing 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 initial interpreting to speed launch times, until native code fragments can be generated by 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 methods 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 OS X uses a Java Shared Archive to provide some of the benefits of shared libraries.

Comparison 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
Common Language Runtime (CLR)	C#, C++/CLI, F#, VB.NET	bytecode is CIL; .NET Core Runtime on GitHub	No	Yes	C#, C++
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)
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#	Common Language Runtime clone	No	Yes	C, C#
Forth	Forth	Features are simplified, usually include assembler, compiler, text-level and binary-level interpreters, sometimes editor, debugger and OS. Compiling 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	Inform 6, Inform 7, others		Yes	No	Various implementations exist
HHVM	PHP, Hack	Is an open-source virtual machine designed for executing programs written in Hack and PHP.	Yes	Yes	C++, OCaml
Icon	Icon	Base source code provides both the interpreter as well as an unsupported compile-to-C version. The runtime code, that is shared between the compiler and the interpreter, is written in a variant of C called RTT.	Yes	No	C, RTT (a custom front-end to C, provided with the base source for Icon).	~180k total. (source to bytecode: ~11k, bytecode interpreter: ~46k, iconc: ~23k, common/headers: ~13k, rtt: ~15k)
JVM	Java, Kotlin, 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, C++, ASM ; IcedTea with the "Zero" JIT : Java, C, C++	JVM is around 6500k lines; TCK is 80k tests and around 1000k lines
LLVM	C, C++, Kotlin, Objective-C, Swift, Ada, Fortran, and Rust	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
Lua	Lua		Yes	LuaJIT	C	13k + 7k LuaJIT
MMIX	MMIXAL
Mono	CLI languages including: C#, VB.NET, IronPython, IronRuby, and others	Common Language Runtime clone	Yes	Yes	C#, C	2332k
NekoVM	currently Neko and Haxe		Yes	x86 only	C	46k
Oz	Oz, Alice
O-code machine	BCPL
p-code machine	Pascal	UCSD Pascal, widespread in late 70s including Apple II	Yes	No	assembly, Pascal
Parrot	Perl 5, Raku, NQP-rx, PIR, PASM, PBC, BASIC, bc, C99, 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 Unladen Swallow	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 let applications run sandboxed inside browser	Yes	Yes	C++	7MB (initially released)
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 & Exupery	Smalltalk/Slang	110k Smalltalk, ~300K C
SWI-Prolog	Prolog: SWI-Prolog, YAP		Yes	No	C, SWI-Prolog
TraceMonkey	JavaScript	Based on Tamarin	No	Yes	C++	173k
TrueType	TrueType	Font rendering engine	Yes	No	C (typically)
Valgrind	x86/x86-64 binaries	Checking of memory accesses and leaks under Linux			C	467k
VisualWorks	Smalltalk		No	Yes	C
Vx32 virtual machine	x86 binaries	Application-level virtualization for native code	No	Yes
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

See also

• Application virtualization
• Language binding
• Foreign function interface
• Calling convention
• Name mangling
• Application programming interface (API)
• Application binary interface (ABI)
• Comparison of platform virtualization software
• List of ECMAScript engines
• WebAssembly