Home

VMKit: a Substrate for Managed Runtime Environments, VEE '10

VMKit: a Substrate for Managed Runtime Environments, VEE '10

Managed Runtime Environments (MREs), such as the JVM and the CLI, form an attractive environment for program execution, by providing portability and safety, via the use of a bytecode language and automatic memory management, as well as good performance, via just-in-time (JIT) compilation. Nevertheless, developing a fully featured MRE, including e.g. a garbage collector and JIT compiler, is a herculean task. As a result, new languages cannot easily take advantage of the benefits of MREs, and it is difficult to experiment with extensions of existing MRE based languages.

This paper describes and evaluates VMKit, a first attempt to build a common substrate that eases the development of high-level MREs. We have successfully used VMKit to build two MREs: a Java Virtual Machine and a Common Language Runtime. We provide an extensive study of the lessons learned in developing this infrastructure, and assess the ease of implementing new MREs or MRE extensions and the resulting performance. In particular, it took one of the authors only one month to develop a Common Language Runtime using VMKit. VMKit furthermore has performance comparable to the well established open source MREs Cacao, Apache Harmony and Mono, and is 1.2 to 3 times slower than JikesRVM on most of the DaCapo benchmarks.

So... One person built a CLR using VMKit in one month. One consequence of such faster development speeds is that language designers do not have to feel so restricted when targeting a Managed Runtime Environment for their language. If the MRE they want to target has restrictions, they can fork it. If the MRE specification has a gray area, then they can quickly prototype a solution to clarify what the behavior should be for that gray area of the specification. If you are a researcher/student and want to experiment with a new language design and implementation, then you can do so incrementally by first augmenting the MRE and then targeting your language to that new MRE; you can then benchmark the improvements by using the original MRE as a baseline.

By Z-Bo at 2010-04-23 19:32 | Cross language runtimes | Implementation | other blogs | 13229 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Implementation

From the paper:

"Our implementation relies on the state of the art third-party projects LLVM for the JIT compiler, MMTk for the garbage collector and the POSIX Thread library for the thread manager. As these projects were not initially designed to work together, a challenge in the development of VMKit has been to define the necessary glue between them to construct an efficient and language-independent substrate, without modifying these projects. Technically, the glue allows the use of an exact GC integrated with the JIT compiler in a multi-threaded environment without imposing the object model, the type system or the call semantics."

From the website: "The VMKit project is an implementation of a JVM and CLI virtual machine (.Net is an implementation of the CLI). It translates Java bytecode and MSIL in the LLVM IR and uses the LLVM framework for optimizations and compilation....Runs any Java and .Net applications on MacOSX and Unix-based systems."

By Josh Stern at Fri, 2010-04-23 21:11 | login or register to post comments

Yes

There is no Windows agenda at this point. Why would you want to run a custom MRE on Windows when (a) Linux networking stack is faster (b) .NET ships with ASP.NET and IIS on the Windows Server product line, anyway (c) you'd be competing with Microsoft in a platform war

As an aside, I do wish .NET was more modular and composable like Mono.

By Z-Bo at Mon, 2010-04-26 02:51 | login or register to post comments

My post above was just

My post above was just trying to give readers more of an abstract about what the VMKit actually is.

To answer your question about "Why would you want to run a customer MRI on Windows", I guess one answer would be that you have other applications running on Windows and you didn't want to reboot.

By Josh Stern at Mon, 2010-04-26 17:20 | login or register to post comments