Chris Lattner on Swift and dynamic dispatch

Re:Chris Lattner on Swift and dynamic dispatch by xxs on Sunday December 13, 2015 @05:02AM (#10725950)

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

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by pvg on Sunday December 13, 2015 @05:17AM (#10725972)

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.

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by xxs on Sunday December 13, 2015 @05:22AM (#10725981)

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.

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by pvg on Sunday December 13, 2015 @05:31AM (#10725997)

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.

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by masklinn on Sunday December 13, 2015 @06:07AM (#10726050)

> 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)

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by pvg on Sunday December 13, 2015 @06:19AM (#10726062)

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.

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by masklinn on Sunday December 13, 2015 @06:40AM (#10726095)

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

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by comex on Sunday December 13, 2015 @11:03AM (#10726645)

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.

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by pjmlp on Sunday December 13, 2015 @01:27PM (#10727231)

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

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by Someone on Sunday December 13, 2015 @01:35PM (#10727270)

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'?

[ Parent | on HN ]

Re:Chris Lattner on Swift and dynamic dispatch by icebraining on Sunday December 13, 2015 @06:05AM (#10726047)

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.

[ Parent | on HN ]