5 ms·

Why not code generate to LLVM which is superior to JVM. Why not make a JVM to LLVM converter as well as a JAVA to LLVM?

throwaway7645 9y ago
Kotlin will soon support LLVM as a target in addition to the JVM. Probably not what you were getting at, but related.
Asooka 9y ago
Because the JVM is much higher level, including object-oriented bytecode letting you jist say "invoke method X on this object", which can in turn be inlined by the JVM using appropriate guards. With LLVM, you'll be forced to "get virtual base class C, read address of method X, jump to location" on every single method call. Not to mention all the array bounds checking which the JVM can remove once it can prove that you're not going outside the bounds. Oh and when debugging you automatically get the unoptimized version of the code when stepping through methods, which I think LLVM can't do (dynamic deoptimization) Edit: the question is moot for Android, since it never used the JVM anyway, but the question is still sensible if you interpret it as "why use high level object oriented vm instead of low level vm"
- lokedhs 9y ago
  To get an idea of how much work is involved in getting LLVM to run a high level language, take a look at Clasp, which does exactly this. It's not a small project and it's definitely not an easy thing to do. https://github.com/drmeister/clasp https://github.com/drmeister/clasp
- DannyBee 9y ago
  Actually, LLVM can do dynamic deopt. It can do the guards. It can also remove the bounds checking for java code. (Azul made all of this work to make it their last tier java compiler). It didn't take that many people or that long. So yeah. (Though in compilers, hard work on existing thing beats shiny shiny almost all of the time)
  - cwyers 9y ago
    > It didn't take that many people or that long. So yeah. Assuming you already have a best-in-class JVM execution platform and have been building JVM execution environments for over a decade, you mean.
    - DannyBee 9y ago
      I'm completely unclear on what point you are trying to make here. The parent was about what LLVM can and can't do. I pointed out it does all the things the parent says it can't, and was made to do those things relatively quickly. I gave a link showing it gives 5-250% better code than hotspot while doing so. I'm not sure what relevance the existing execution platform would have to any of that. As far as I can tell, it has "none". Among other reasons, what the last tier compiler does has to be better than the other tiers, or it's a pointless waste of time. It's not like it can generate worse code and you can get away with it. It also was not built in a way that requires their jvm execution platform, or anything like that. You could take it and hook it into another JVM if you wanted, in roughly the same time frame. The only difference is that instead of pretending it's hard or impossible, they just did the hard work to do it. If the point you are trying to make is that you can't use it as a first tier or second tier jit, and that it would never work without some magical existing jvm technology, this would also be wrong. "and have been building JVM execution environments for over a decade, you mean" The folks involved had not. Really. I feel like you are just going off on a random tangent without a lot of data here, just because you don't want to say "yeah, i guess the parent was wrong". I could also point out that LLVM is just about as old as Hotspot, for example (1999 vs 2000), and both are a decade older than Azul's compilers (2010).
      - cwyers 9y ago
        > I feel like you are just going off on a random tangent without a lot of data here, just because you don't want to say "yeah, i guess the parent was wrong". Okay, but, uh... having never been involved in the conversation until that point, I could have just... not said anything about the parent? It just sounded like you were trivializing something which likely wasn't an easy thing to do.
tanilama 9y ago
> LLVM which is superior to JVM Link? Superior in what way? Is there any LLVM based JVM implementation that runs faster than the current JVM android is using and no compatibility issue? When I see those claims without any actual code, I would stay suspicious and call it farce, until it proves itself.
- theoh 9y ago
  You must mean "false" not "farce". I can't see how such claims could be considered farcical.
- DannyBee 9y ago
  "Link? Superior in what way? Is there any LLVM based JVM implementation that runs faster than the current JVM android is using and no compatibility issue? " Yes. Azul uses LLVM as its last tier JIT compiler now :) I don't think anyone is going to argue they don't have the fastest JVM around. See http://www.infoworld.com/article/3193078/java/azul-introduces-llvm-compiler-to-java-runtime.html http://www.infoworld.com/article/3193078/java/azul-introduce... The performance numbers they give are: " Falcon bests Oracle's HotSpot Java platform by anywhere from 5 to 250 percent in production performance, depending on the application, according to Azul. "
  - tanilama 9y ago
    And you forget to quote: > Based on the LLVM compiler platform, designed for server workloads, and optimized for recent Intel and AMD architectures Server and mobile application have vastly different assumption of workload and metrics to take a look at. However, this announcement definitely better than OP's vague performance claim, which I agree. But as I said, there is no proof at this point, that LLVM based implementation on Android improve the the performance. Quite on the contrary, Google include LLVM in 5.0 then remove it later: https://www.quora.com/What-are-the-technical-details-of-the-Android-ART-runtime-introduced-in-Android-4-4/answers/10044855?srid=XwOv https://www.quora.com/What-are-the-technical-details-of-the-... And it was never used as the primary option anyway. So there is definitely not enough confidence to claim the superiority, until somehow make it work in the first place.
johncolanduoni 9y ago
Android devices after 5.0 (when ART was introduced) precompile ~~JVM~~ Dalvik bytecode to LLVM on the way to native code. If you want to deploy native code that was compiled via LLVM, you've been able to do that for a while. The native API is pretty crappy, but trying to shoehorn LLVM IR into a Java bytecode replacement (which is not an easy task, see PNaCl) doesn't do anything to help. Edit: ART handles Dalvik bytecode, not Java bytecode.

Kotlin will soon support LLVM as a target in addition to the JVM. Probably not what you were getting at, but related.

Because the JVM is much higher level, including object-oriented bytecode letting you jist say "invoke method X on this object", which can in turn be inlined by the JVM using appropriate guards. With LLVM, you'll be forced to "get virtual base class C, read address of method X, jump to location" on every single method call. Not to mention all the array bounds checking which the JVM can remove once it can prove that you're not going outside the bounds. Oh and when debugging you automatically get the unoptimized version of the code when stepping through methods, which I think LLVM can't do (dynamic deoptimization) Edit: the question is moot for Android, since it never used the JVM anyway, but the question is still sensible if you interpret it as "why use high level object oriented vm instead of low level vm"

lokedhs 9y ago
To get an idea of how much work is involved in getting LLVM to run a high level language, take a look at Clasp, which does exactly this. It's not a small project and it's definitely not an easy thing to do. https://github.com/drmeister/clasp https://github.com/drmeister/clasp
DannyBee 9y ago
Actually, LLVM can do dynamic deopt. It can do the guards. It can also remove the bounds checking for java code. (Azul made all of this work to make it their last tier java compiler). It didn't take that many people or that long. So yeah. (Though in compilers, hard work on existing thing beats shiny shiny almost all of the time)
- cwyers 9y ago
  > It didn't take that many people or that long. So yeah. Assuming you already have a best-in-class JVM execution platform and have been building JVM execution environments for over a decade, you mean.
  - DannyBee 9y ago
    I'm completely unclear on what point you are trying to make here. The parent was about what LLVM can and can't do. I pointed out it does all the things the parent says it can't, and was made to do those things relatively quickly. I gave a link showing it gives 5-250% better code than hotspot while doing so. I'm not sure what relevance the existing execution platform would have to any of that. As far as I can tell, it has "none". Among other reasons, what the last tier compiler does has to be better than the other tiers, or it's a pointless waste of time. It's not like it can generate worse code and you can get away with it. It also was not built in a way that requires their jvm execution platform, or anything like that. You could take it and hook it into another JVM if you wanted, in roughly the same time frame. The only difference is that instead of pretending it's hard or impossible, they just did the hard work to do it. If the point you are trying to make is that you can't use it as a first tier or second tier jit, and that it would never work without some magical existing jvm technology, this would also be wrong. "and have been building JVM execution environments for over a decade, you mean" The folks involved had not. Really. I feel like you are just going off on a random tangent without a lot of data here, just because you don't want to say "yeah, i guess the parent was wrong". I could also point out that LLVM is just about as old as Hotspot, for example (1999 vs 2000), and both are a decade older than Azul's compilers (2010).
    - cwyers 9y ago
      > I feel like you are just going off on a random tangent without a lot of data here, just because you don't want to say "yeah, i guess the parent was wrong". Okay, but, uh... having never been involved in the conversation until that point, I could have just... not said anything about the parent? It just sounded like you were trivializing something which likely wasn't an easy thing to do.

tanilama 9y ago

> LLVM which is superior to JVM Link? Superior in what way? Is there any LLVM based JVM implementation that runs faster than the current JVM android is using and no compatibility issue? When I see those claims without any actual code, I would stay suspicious and call it farce, until it proves itself.

theoh 9y ago
You must mean "false" not "farce". I can't see how such claims could be considered farcical.
DannyBee 9y ago
"Link? Superior in what way? Is there any LLVM based JVM implementation that runs faster than the current JVM android is using and no compatibility issue? " Yes. Azul uses LLVM as its last tier JIT compiler now :) I don't think anyone is going to argue they don't have the fastest JVM around. See http://www.infoworld.com/article/3193078/java/azul-introduces-llvm-compiler-to-java-runtime.html http://www.infoworld.com/article/3193078/java/azul-introduce... The performance numbers they give are: " Falcon bests Oracle's HotSpot Java platform by anywhere from 5 to 250 percent in production performance, depending on the application, according to Azul. "
- tanilama 9y ago
  And you forget to quote: > Based on the LLVM compiler platform, designed for server workloads, and optimized for recent Intel and AMD architectures Server and mobile application have vastly different assumption of workload and metrics to take a look at. However, this announcement definitely better than OP's vague performance claim, which I agree. But as I said, there is no proof at this point, that LLVM based implementation on Android improve the the performance. Quite on the contrary, Google include LLVM in 5.0 then remove it later: https://www.quora.com/What-are-the-technical-details-of-the-Android-ART-runtime-introduced-in-Android-4-4/answers/10044855?srid=XwOv https://www.quora.com/What-are-the-technical-details-of-the-... And it was never used as the primary option anyway. So there is definitely not enough confidence to claim the superiority, until somehow make it work in the first place.

johncolanduoni 9y ago

Android devices after 5.0 (when ART was introduced) precompile ~~JVM~~ Dalvik bytecode to LLVM on the way to native code. If you want to deploy native code that was compiled via LLVM, you've been able to do that for a while. The native API is pretty crappy, but trying to shoehorn LLVM IR into a Java bytecode replacement (which is not an easy task, see PNaCl) doesn't do anything to help. Edit: ART handles Dalvik bytecode, not Java bytecode.