3 ms·
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
by 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 agoHe 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 agoYou 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 agoNot 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.
- pjmlp 11y ago> You can't really AOT compile java and have it be java IBM J9, Aonix PERC, Excelsior JET, JamaicaVM, RoboVM are just a few of the commercial JVMs that also AOT compile Java. Oracle is also planning to have AOT as an option in future versions of the compiler.
- Someone 11y agoI 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'?