A JVM Does That?

Cliff Click was the jvm architect at sun then spent a decade at azul systems as their jvm architect. The talk is "A JVM Does That?" It's well worth watching if you are interested in vms at all. [VIDEO]

Probably this one: [LINK] Anything from Cliff Click is quite good. This guy has a very deep understanding of compilers, virtual-machines, CPUs, and their interactions. A JVM does that? [VIDEO] Java on a 1000 Cores [LINK]

There are some interesting challenging when scaling this large with any system. Peter referenced some of Azul System's stuff and their custom GC. Cliff Click from Azul has done some great Google Tech Talks about JVM development and scaling JVM's out to really big systems.[1][2] [1] A JVM Does That? - [VIDEO] [2] Java on a 1000 Cores - [LINK]

I'm not part of the Java world at all, but I'm starting to think that Azul Systems is one of the few groups of people who know what they're doing with regard to Linux performance and the user/kernel boundary. I recently watched some talks by Cliff Click[1] that were extremely informative, and from what I understand about their proposed kernel patches, they seem like important improvements. This report by Gil Tene (their CTO according to Wikipedia) lends more support to that theory. [1] [VIDEO]

There is a fascinating talk by Cliff Click "A JVM Does That?" At the end he shares some opinion about what should be done by JVM or OS and what should change. video: [VIDEO] slides: [LINK] I remember a talk, where he was also talking about hardware. It does not seem to be this one. For example, a time register would be useful. Syscalls like clock_gettime are too slow. CPU info like cycle counts fail with dynamic frequency scaling.

IBM's Metronome[1] advertises maximum pause times in the hundreds of micro seconds range. Cliff Click[2] cites a 10MB max heap for it so definitely not a cure-all but definitely something I'd like to play around with. [1] [LINK] [2] [VIDEO]

Well, LLVM is something else altogether, as it doesn't try to abstract away the OS, while the JVM does[1]. As to the JVM, well, first of all, there is no "the JVM". There are many JVMs by many vendors, and many types of JVMs (from smart-cards, through various embedded devices, and all the way to desktops, servers and mainframes). Some of the most interesting -- and most important -- ones are made by companies you've probably never heard of, like Aicas and Atego that make hard realtime JVMs for use in avionics, medical devices and other safety-critical systems. The best-known JVMs are HotSpot, OpenJDK's JVM (which serves as the basis for Oracle and Azul's JVMs) and J9, IBM's JVM. When many people say "the JVM" they mean the SE (i.e. "standard edition") of HotSpot. While HotSpot and the CLR are more similar -- at least in their goals -- than different, and each is ahead of the other in some respects and behind in others, I'd say that the most interesting features of HotSpot are its JIT and GCs (it comes with a few) that are years ahead of anything else used in any other environment in the industry (well, except Azul that sells a modified HotSpot with a "pauseless" GC that never pauses the application for more than a few microseconds). In my opinion, the most exciting development regarding HotSpot is the work being done on HotSpot's next generation optimizing JIT called Graal, that comes with an a complementary language toolkit called Truffle[2]. It pushes the envelopes further

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]: [VIDEO]