The Cloud Native Compiler: JIT-as-a-Service

Track: Java Platform
Adaptive, just in time (JIT) compilation provides a massive performance improvement to JVM-based applications compared to only using an interpreter. The downside of this is that applications have to compile frequently used methods as the application is running. This can lead to reduced throughput and slower response times. Another drawback is that each time an application is started, it must perform the same analysis to identify hot spot methods and compile them. When running an application in the cloud, the elastic nature of resources provides the ability to change and improve the dynamics of how the JIT compiler works. In this session, we'll look at Azul's work to move the JIT compiler into a centralized service that can be shared by many JVMs. This provides many advantages, such as caching compiled code for instant delivery when restarting the same application or spinning up new instances of the same service. In addition, it removes the workload from individual JVMs, allowing them to deliver more transactions per second of application work. Finally, there is the opportunity to apply considerably more compute resources to enable complex optimizations to be used that wouldn't be practical in a single JVM.
Simon Ritter
Simon Ritter is the Deputy CTO of Azul Systems. Simon has been in the IT business since 1984 and holds a Bachelor of Science degree in Physics from Brunel University in the U.K. Simon joined Sun Microsystems in 1996 and started working with Java technology from JDK 1.0; he has spent time working in both Java development and consultancy. Having moved to Oracle as part of the Sun acquisition, he managed the Java Evangelism team for the core Java platform, Java for client applications and embedded Java. Now at Azul, he continues to help people understand Java as well as Azul’s JVM technologies and products. Simon has twice been awarded Java Rockstar status at JavaOne and is a Java Champion. He currently represents Azul on the JCP Executive Committee and on the Java SE Expert Group (JSR 379, 383 and 384).