Channels ▼
RSS

Design

The Ubiquitous VMs


Virtual machines, those magical bits of software that execute bytecodes, are such an excellent solution to so many problems that they have become, in many ways, the default solution where portability is an overriding consideration and performance is not critical. While VMs have been a part of computing for almost 50 years, they did not really become widely popular until the advent of Perl, Python, Java, and .NET. The last two, of course, established VMs as a standard platform for program execution and demonstrated what was suspected but not proven — that VMs could be optimized to run code at speeds comparable to native code.

Since that inflection point, VMs have proliferated. When I look at my primary work system, I find the same collection of VMs that I suspect many other developers carry with them: the JVM, .NET, Python, Ruby, several JavaScript VMs, and a few more. That few more, depending on the system I'm using, could include VMs for Lua, Perl, Erlang, Haxe, and the LLVM infrastructure. There's also a VM on my phone — Android Dalvik.

But I'm not close to done. The font hinting in TrueType uses a VM, SQLite uses one, and Valgrind — that most excellent tool for C programmers — uses one, too. Given this profusion — and I am surely overlooking other instances — it's incumbent to reconsider the VM's role in software development.

About five years ago, there was a sudden surge in the popularity of DSL creation. Languages such as Groovy and Scala made it easy to invent simple languages that implemented niche programmatic solutions. These tools satisfied an urge that all developers feel at one time or another, which is to be able to express problems and solutions in the domain language. Such DSLs are fine as far as they go, but they frequently have a certain artificiality to their syntax that feels like forcing a fit that does not naturally exist.

Virtual machines represent a more holistic solution. The expressivity is now unlimited since any term can be used as part of the language and, importantly, the VM can customize program execution to fit exactly with the requirements of the domain. For example, the Lua VM is designed to be small and capable of quick loading to execute small programs. It's not designed for parallel programming and so does not support multithreading (which is a forte of the Erlang VM).

But more than the ability to implement domain-specific idioms well, the factors that make VMs so popular are their portability and the ease with which they can be written. The portability is well known. To port a language to a new platform, only the VM need be compiled for the new target and all existing programs should, in theory, work unmodified. (To be accurate, for large VM platforms, like the JVM, this porting is considerably more complicated.)

Ease of implementation is also attractive. Many VMs are small affairs that typically do not exceed 10-20K LOC, many of them being even smaller. And the basic model — a giant switch statement that reads the bytecodes and branches to the corresponding execution routine — is easy to understand and implement. Only when performance is critical and compiling on-the-fly using a JIT is required do VMs become complex tools to implement.

Because VMs are highly customized to the language and domain they're designed for, they tend to be poor at running multiple languages. They often contain language-specific assumptions in their execution model and they support only a limited set of types (note, for example, the absence of unsigned integers in Java). VM projects that aim to run numerous languages tend not to fare well (Parrot, for example) — with the notable exception of the LLVM, which succeeded primarily due to substantial investments and a large, active community.

Because of this specificity and the comparative simplicity of writing a new VM, I expect they will continue to proliferate on the systems we use daily and be increasingly implemented within many other technologies.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Comments:

AndrewBinstock
2013-12-26T20:07:05

It's not petty at all. I appreciate the comment. It's sometimes difficult to judge exactly which abbreviations need to be expanded--especially with a heterogeneous audiences--and which ones don't.


Permalink
ubm_techweb_disqus_sso_-2ea949ebab57a39321967fa14428cd21
2013-12-24T00:24:10

I suppose I'm being petty; but, when writing papers in scientific journals, it was expected (with few exceptions) that abbreviations would be explained upon first use in every paper, e.g., "...virtual machines (VMs)...", especially if they might be confused with another common abbreviation. I haven't a clue what 'DSL' means in this context—no doubt because I do not read the trade literature as often as I was once wont to do.


Permalink
ubm_techweb_disqus_sso_-09a9d031ab1ec9d0e017141b26dbb45e
2013-12-18T18:52:16

Unfortunately, VMs offer yet another attack vector for malware.


Permalink
ubm_techweb_disqus_sso_-c8812b0acec7046432d429102c84852d
2013-12-18T08:02:34

What LLVM homepage says - Despite its name, LLVM has little to do with traditional virtual machines ...


Permalink
ubm_techweb_disqus_sso_-12013654d015384efe1eab46e654cc19
2013-12-18T04:21:32

I have been involved with Lua for some time now and I love the language and its small footprint, I use LuaJIT - blazing fast!. So, is Parrot dead?, or it will continue to be associated with Perl alone ?


Permalink

Video