

VMKit: JVM and .Net runtimes for LLVM - prog
http://vmkit.llvm.org/

======
albertzeyer
It's said that it can already execute such large projects as Eclipse. Has
anyone tried that and can compare the performance (and the memory resources it
needs) to the Sun VM? I would love to see a VM which takes less memory and has
better performance.

~~~
neilc
From the abstract of the paper:

 _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_

Going through VMKit to get improved JVM performance seems a little redundant.

------
lenni
Can the JVM bytecode and the .Net assemblies somehow magically make use of
each other or do you have to choose which one you target? If you can't this
seems to be "just" an implementation of each platform, right?

~~~
kevingadd
My guess is that they could make use of each other if you had a way to expose
method signatures from one environment to the other environment.

As an example, the IKVM project acts as a Java runtime within the .NET
environment, and lets you create .NET classes that wrap java classes so you
can use them from within .NET. My understanding is that IKVM works by
translating Java bytecodes/signatures to the .NET equivalents.

Note that while translation in one direction - Java to .NET - is relatively
easy (mostly due to the fact that .NET offers almost all the features that
Java has), the other direction is more difficult due to the large number of
features in .NET that don't have direct Java equivalents. One simple example:
.NET APIs make heavy use of delegate types, which would all have to be
translated into listener interfaces or something similar to be Java-friendly.
Translating .NET structs would also be difficult, since their value-type
behavior would be somewhat hard to reproduce using Java classes.

~~~
j_baker
Delegates could be done in java albeit not trivially. They're essentially just
syntactic sugar for a one-method class.

I would be a bit more worried about handling generics. The CLI has true
generics while Java's generics are syntactic sugar for casting to and from
object.

~~~
bad_user
> * Delegates could be done in java albeit not trivially. They're essentially
> just syntactic sugar for a one-method class.*

No, there are many differences, both at the language and at the VM level,
although you could emulate the behavior of delegates. You should look at the
new MethodHandler from the JDK7 InvokeDynamic proposal ... they've added it
for a reason ;)

> _The CLI has true generics_

The jury is still out on what constitutes "true generics" ... IMHO the C++
templates are more true than their C# equivalent ;)

But yeah, the Java generics system is a far cry from what it should've been.
And it also sucks because there are exceptions ... arrays are reified, and the
new MethodHandler from JDK7 is also reified.

That said ... you can add reified generics on top of the JVM. It is just a lot
of hard work because you can't reuse the current generic types.

There are other features that are difficult to implement ... stack allocated
values, the primitives that aren't mapping to the JVM types (decimal, ulong),
pointers / unsafe code, PInvoke, tail-calls (although I know of a way to have
tail-calls, but it's heavy).

You can implement anything on top of the JVM, but you will lose efficiency
(not to mention of interoperability with Java code).

~~~
DrJokepu
_...tail-calls..._

Note that neither the Microsoft C# compiler nor the Mono one emit tail calls.
In practice, the MS .NET Just-In-Time compiler however transforms tail
recursion to loops even if the compiler didn't ask for it if a number of
conditions are met. I'm no JVM expert by any means but I don't see why the JVM
couldn't do something similar, in theory or in practice.

~~~
bad_user
> _Note that neither the Microsoft C# compiler nor the Mono one emit tail
> calls_

The F# compiler does, and not just for self-recursive calls.

> _the MS .NET Just-In-Time compiler however transforms tail recursion to
> loops_

The hard problem is to have mutually recursive functions ... A() calls B()
calls C() calls A().

I'm currently working on a compiler that behind the scenes implements
trampolines, so if you had something like ...

    
    
      int methodA() {
          // does something here
          return methodB("calling B");
      }
    

This would be translated to something like (pseudocode) ...

    
    
      int methodA(TailCallException ex) {
          // do something here
    
          ex.method = methodB;
          ex.args   = [ 'calling B' ];
          throw ex;
      }
    
      // trampoline implemented for any method with tail-calls
      int methodA() {
          int result;
          has_next = true;
          method = reference to methodA;
          args   = []
    
          // reusing the same TailCallException instance
          exc = new TailCallException(); 
    
          while (has_next) {
              try {
                  result = method.invoke(args, exc);
                  has_next = false;
              }
              catch (TailCallException ex) {
                  method = ex.method;
                  args   = ex.args;
              }
          }
    
          return result;
      }
    

So yeah, it's possible. But this is overkill for functional languages where
you've got recursion all over the place.

------
c00p3r
Arc runtime for LLVM would be much greater news..

------
albertzeyer
Ah, and LLVM ftw!! :)

