4 HN users recommended this talk5 months2011–2017score 5.5
Years with an HN recommendation, 2007–2026
A repeated recommendation for anyone interested in VMs, with Click's talks regarded as unusually informative on JVMs, JITs and the user/kernel boundary.
Cliff Click of Azul Systems asks what a JVM is supposed to do, in a Google Tech Talk from 2011. He covers the services a JVM provides, such as garbage collection and compilation, and the messy reality beneath the abstractions.
“It's well worth watching if you are interested in vms at all.” (HN, 2016)
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. [this 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? [this 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? - [this video] [2] Java on a 1000 Cores - [link]
Cliff Click talk on JVM development and big-system scaling
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] [this video]
Informative talks on performance and the user/kernel boundary
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: [this 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.
Cliff Click's opinions on JVM versus OS responsibilities
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] [this 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
Cited in a broad discussion of JVM implementations
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]: [this video]
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
8 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more
Read more