5 ms·

VMKit: JVM and .Net runtimes for LLVM

71 points by prog 16y ago

lenni 16y ago
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 16y ago
  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 16y ago
    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.
    - DrJokepu 16y ago
      Delegates ... are essentially just syntactic sugar for a one-method class No that's not entirely true. There are a lot of similarities but there are essential differences as well. Delegates in .NET are truly functions as first class objects while single-method anonymous classes is Java are first class object wrappers around functions. This means that while in Java an anonymous class is a tuple with a reference to the instance of the anonymous class and a reference to the instance of the container class, in .NET it is a tuple with a reference (pointer actually) to a method and a reference to the instance of the owner class (if not static). This is a subtle but important difference and is entrenched all the way down in the .NET type system, not just on syntax level.
    - bad_user 16y ago
      > * 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 16y ago
        ...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.
        prog 16y ago
        Scala compiler does self-tail calls so in theory Java compiler should be able to do it. But IIUC doing tail calls between functions is not possible (or at least not worth the effort) on the JVM.
        bad_user 16y ago
        > 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 16y ago
Arc runtime for LLVM would be much greater news..
albertzeyer 16y ago
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 16y ago
  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.
albertzeyer 16y ago
Ah, and LLVM ftw!! :)

71 points by prog 16y ago

lenni 16y ago

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 16y ago
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 16y ago
  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.
  - DrJokepu 16y ago
    Delegates ... are essentially just syntactic sugar for a one-method class No that's not entirely true. There are a lot of similarities but there are essential differences as well. Delegates in .NET are truly functions as first class objects while single-method anonymous classes is Java are first class object wrappers around functions. This means that while in Java an anonymous class is a tuple with a reference to the instance of the anonymous class and a reference to the instance of the container class, in .NET it is a tuple with a reference (pointer actually) to a method and a reference to the instance of the owner class (if not static). This is a subtle but important difference and is entrenched all the way down in the .NET type system, not just on syntax level.
  - bad_user 16y ago
    > * 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 16y ago
      ...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.
      - prog 16y ago
        Scala compiler does self-tail calls so in theory Java compiler should be able to do it. But IIUC doing tail calls between functions is not possible (or at least not worth the effort) on the JVM.
      - bad_user 16y ago
        > 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 16y ago

Arc runtime for LLVM would be much greater news..

albertzeyer 16y ago

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 16y ago
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.

albertzeyer 16y ago

Ah, and LLVM ftw!! :)