[LLVMdev] VMKit state of the union, android support, and .net/CLI

Gaël Thomas gael.thomas at lip6.fr
Sun Sep 15 00:33:09 PDT 2013

Hi Jeremy,

2013/9/13 Jeremy Bell <bell.jeremy at gmail.com>:
> I looked into the archives as far back as 2009 and searched around for more
> information about vmkit, but I still have some questions.
> First of all, what is that status of VMKit? Is there any active development?
> A roadmap? Is it in maintenance mode?

The development is inactive since two month because the main engineer
of VMKit is now working for a big company (cool for him, but that's
why I was so slow to answer your mail:)). For the moment, we are in
maintenance mode, but a new engineer will probably start working on
the project in two or three weeks. And we have a roadmap, we are
currently implementing a new VM for the Scilab language and we are
developing a clang pass to help the development of new VMs. Basically,
the clang pass is able to generate the glue between the C code and the
GC, as it was presented in ISMM few years ago by another team (Jon
Rafkind, Adam Wick, John Regehr, Matthew Flatt: Precise garbage
collection for C. ISMM 2009).

> Secondly, can VMKit generate binaries that can be used on android/jni?

As android relies on Linux, it's probably easy to generate binaries
compliant with android (VMKit runs on Linux and MacOS). The problem
that can arise is related to the processor: we have only tested VMKit
on x86_32, x86_64 and powerpc architectures, not on arm
architectures... Porting VMKit on arm should not be so complicated as
llvm has already a backend for this architecture. It's probably a
matter of defining the size of the word for this architecture.

By JNI, you mean the Java Native Interface? On one way, as VMKit
generates native code with LLVM, you can link this code with a JNI
library and use the generated code in any Java virtual machine.
However, using VMKit through JNI requires the implementation of a
small wrapper because VMKit defines its own threads and a Java virtual
machine also. It probably means that you should have an intermediate
JNI threads that forwards the JNI calls to the VMKit threads. On the
other way, J3, the Java virtual machine built upon VMKit, is a full
Java virtual machine and fully implements JNI itself.

> Finally, I understand that the .net/CLI support is no longer being
> maintained. Were there technical reasons for this, or just a lack of
> interest? Is the code still within the repository or was it removed at some
> point? If it was removed, what is the last tag/version of the code contains
> the .net/CLI implementation?

We haven't maintained the CLI since three years because we didn't have
the time for that (we are a small team:)). You should find the code in
the repository. If you need it I can try to find the last revision.
Anyway, even if you are able to find this code, you will have to use a
very old version of llvm to compile it, and the vmkit version will be
very old with a lot of bugs... So, you will have to port the code of
N3 (the .Net virtual machine) on the latest VMKit release, which can
take few weeks because everything has changed in VMKit :) (N3 was
relying on the Boehm GC while we are currently using MMTk).

> The reason I ask is that I took over a project to bring Mono to android for
> open source development. You can see it here:
> https://github.com/JeroMiya/androidmono

Great project!

> But development hit a wall due to licensing, because Xamarin, the company
> that develops mono, sells commercial licenses for Mono to use in place of
> the LGPL on embedded platforms like Android/iOS, and claims that the LGPL is
> not compatible with the Play store. While I disagree (as does the FSF as I
> recall), I'm not a lawyer and can't justify hiring one for a hobbyist
> project. In either case, it's clear Xamarin has become hostile to open
> source development with their product, so it's not something I want to test.
> This means apps built using my project could only be distributed directly
> (via sideloading) or via F-Droid or other open source friendly third party
> app stores, even if they're open source apps.
> So, I've been shopping around for alternatives to the LGPL portions of the
> Mono runtime which can more easily be licensed for open or closed source
> development on mobile or restricted app store deployments. The only credible
> alternatives I've found so far are the .Net MicroFramework, which is
> licensed under Apache but is meant for low level hardware, and VMKit, which
> sounds promising but the .Net implementation has been deprecated.
> If someone is more familiar with the VMKit codebase, could you comment on
> what kind of work would be needed to update the existing CLI implementation
> of VMKit to the latest source?

As I said, it should not be so difficult. For someone familiar with
VMKit, it will take one month. And understanding the code of VMKit
takes around one month more.

> Also, what features still need to be
> implemented, and what barriers have been identified?

We haven't identified barriers. The N3 runtime was minimal and we were
able to execute several scientific benchmarks. Having a full .Net
virtual machine with all the bytecodes is probably only a matter of

> I'm not expecting
> anything production ready by any means, and I'm willing to do the work as
> long as there's at least a chance at success.

If you start this work, we can try to help you to understand the code
(we can not help for implementation itself as, for the moment, we
don't have a lot of manpower). Having an android version of VMKit
could be fun, and having the .Net virtual machine resurrected could be
pretty cool :)


PS: if you start playing with VMKit, we have a bug that we are unable
to solve yet with the last version of openjdk. We are only able to
compile VMKit with the version 7u23 of openjdk.

> Thanks for your time!
> Regards,
> Jeremy Bell
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Gaël Thomas, Associate Professor, UPMC

More information about the llvm-dev mailing list