5 ms·

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

by 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.

by Asooka 9y ago

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.