4 ms·

JITs do know the call target. This is a quote from "A JVM does that?"[0]: C++ avoids virtual calls – because they are slow ● Java embraces them – and makes

by xxs 11y ago

JITs do know the call target. This is a quote from "A JVM does that?"[0]: C++ avoids virtual calls – because they are slow ● Java embraces them – and makes them fast ● Well, mostly fast – JIT's do Class Hierarchy Analysis ● CHA turns most virtual calls into static calls ● JVM detects new classes loaded, adjusts CHA – May need to re-JIT ● When CHA fails to make the call static, inline caches ● When IC's fail, virtual calls are back to being slow ---- There are several misconception about Java in the write-up. The real reason there won't be a bootloader is the need for the Java runtime and the need to GC. Unoptimized virtual calls won't affect any bootloader for that matter (and you can/should use static and/or private methods for the inner loops) [0]:https://www.youtube.com/watch?v=uL2D3qzHtqY https://www.youtube.com/watch?v=uL2D3qzHtqY

pvg 11y ago
He doesn't say you won't see a Java bootloader because of unoptimized virtual calls, he says it's because the runtime is too big. CL: It also means that Java doesn’t “scale down” well to small embedded systems that can’t support a JIT, like a bootloader.
- xxs 11y ago
  OTOH, since the compilation model assumes a JIT, this means that purely “AOT” static compilers (which have no profile information, no knowledge of class loaders, etc) necessarily produce inferior code. It also means that Java doesn’t “scale down” well to small embedded systems that can’t support a JIT, like a bootloader. This the quote. He talks about the JIT only, no runtime mentioned.
  - pvg 11y ago
    He might somewhat tersely be conflating JIT and 'runtime'as whole - see the mention of classloaders but his meaning is clear, it's about size rather than performance. 'It also means' etc.
    - masklinn 11y ago
      > it's about size rather than performance. The tradeoff really: what he's saying is that you can JIT java to get speed but you'll lose size (resident), or you can AOT compile java to improve size but then you lose speed because calls may not be possible to devirtualize (unless you have PGO maybe? You'd lose some speed and size to guards and duplicated dispatch though)
      - pvg 11y ago
        You can't really AOT compile java and have it be java and it seems fairly obvious to me he's talking about size and runtime-related things, in which he throws in a JIT (i.e. the compilation model 'assumes' a JIT). I think he's just being slightly loose with his terminology because he's just replying on a mailing list without expectation that random nerds on an internet forum will be talumidcally dissecting his semiotic intent.
        masklinn 11y ago
        > You can't really AOT compile java and have it be java Of course you can. > and it seems fairly obvious to me he's talking about size and runtime-related things I'm not sure why you're so intent in reinterpreting his rather plain words (and insulting people when they don't agree with your broad reinterpretation). Lattner is literally just noting that an AOT-compiled java program has no knowledge of java's dynamic semantics (classloader &al), so it can't devirtualize calls and must necessarily pay the dynamic dispatch cost, in the same way e.g. messages in objective-c can't be devirtualized. In essence, an AOT java is slightly better than a straight interpreter but not by much. The whole essay is about static versus dynamic dispatch and how languages provide for those, it's not exactly a stretch to assume that when Lattner talks about inferior code that's what he's talking about: bootloader = no JIT = pervasive dynamic dispatch = slow, you don't have to bring your own pet issues into that.
        comex 11y ago
        Not nearly as bad as an interpreter, especially if you do whole program optimization. In fact, Android switched from the Dalvik JIT to ART, which compiles AOT-ish.
  - Someone 11y ago
    I don't think you can have a JIT without a runtime. Something has to decide when it is 'just in time' to compile a piece of code, and something has to run the piece before it gets JITted. Or am I overlooking a narrower definition of 'runtime'?
icebraining 11y ago
Maybe I'm missing something, because people have implemented JVMs on embedded systems, including GC. An example is lejOS, which runs on the Lego Mindstorms, including the original RCX with its 8-bit microcontroller and 32K of RAM.

by xxs 11y ago

pvg 11y ago

He doesn't say you won't see a Java bootloader because of unoptimized virtual calls, he says it's because the runtime is too big. CL: It also means that Java doesn’t “scale down” well to small embedded systems that can’t support a JIT, like a bootloader.

xxs 11y ago
OTOH, since the compilation model assumes a JIT, this means that purely “AOT” static compilers (which have no profile information, no knowledge of class loaders, etc) necessarily produce inferior code. It also means that Java doesn’t “scale down” well to small embedded systems that can’t support a JIT, like a bootloader. This the quote. He talks about the JIT only, no runtime mentioned.
- pvg 11y ago
  He might somewhat tersely be conflating JIT and 'runtime'as whole - see the mention of classloaders but his meaning is clear, it's about size rather than performance. 'It also means' etc.
  - masklinn 11y ago
    > it's about size rather than performance. The tradeoff really: what he's saying is that you can JIT java to get speed but you'll lose size (resident), or you can AOT compile java to improve size but then you lose speed because calls may not be possible to devirtualize (unless you have PGO maybe? You'd lose some speed and size to guards and duplicated dispatch though)
    - pvg 11y ago
      You can't really AOT compile java and have it be java and it seems fairly obvious to me he's talking about size and runtime-related things, in which he throws in a JIT (i.e. the compilation model 'assumes' a JIT). I think he's just being slightly loose with his terminology because he's just replying on a mailing list without expectation that random nerds on an internet forum will be talumidcally dissecting his semiotic intent.
      - masklinn 11y ago
        > You can't really AOT compile java and have it be java Of course you can. > and it seems fairly obvious to me he's talking about size and runtime-related things I'm not sure why you're so intent in reinterpreting his rather plain words (and insulting people when they don't agree with your broad reinterpretation). Lattner is literally just noting that an AOT-compiled java program has no knowledge of java's dynamic semantics (classloader &al), so it can't devirtualize calls and must necessarily pay the dynamic dispatch cost, in the same way e.g. messages in objective-c can't be devirtualized. In essence, an AOT java is slightly better than a straight interpreter but not by much. The whole essay is about static versus dynamic dispatch and how languages provide for those, it's not exactly a stretch to assume that when Lattner talks about inferior code that's what he's talking about: bootloader = no JIT = pervasive dynamic dispatch = slow, you don't have to bring your own pet issues into that.
        comex 11y ago
        Not nearly as bad as an interpreter, especially if you do whole program optimization. In fact, Android switched from the Dalvik JIT to ART, which compiles AOT-ish.
- Someone 11y ago
  I don't think you can have a JIT without a runtime. Something has to decide when it is 'just in time' to compile a piece of code, and something has to run the piece before it gets JITted. Or am I overlooking a narrower definition of 'runtime'?

icebraining 11y ago

Maybe I'm missing something, because people have implemented JVMs on embedded systems, including GC. An example is lejOS, which runs on the Lego Mindstorms, including the original RCX with its 8-bit microcontroller and 32K of RAM.