Mikael Vidstedt and Staffan Friberg presented ‘Looking into the JVM Crystal Ball.’ They stated that the two primary areas of coverage for this presentation are technical VM details and the VM roadmap. An early slide, ‘VM Convergence,’ talked about the convergence of JRockit and HotSpot as well as the CDC (Jave ME) and HotSpot Embedded convergence.
A slide on ‘Serviceability: Introspection and Analysis’ talked about desire for ‘unified logging’ (JEP 158) and ‘native memory tracking.’ Another slide with the same title talked about ‘Java Flight Recorder and Java Mission Control’ that is a licensed feature in JRockit that will be available in HotSpot (still as a licensed feature).
A ‘Just Say Java’ bullet refers to intent to ‘remove artificial memory limits and required tuning’ and to ‘reduce the complexity of tuning the garbage collector.’ The end goal is a ‘single scalable VM for both client and server’ using a ‘multi-tiered optimizing compiler.’ Another slide with the same ‘Enterprise: Server Java’ title talked about ‘instant performance,’ ‘low latency garbage collector,’ and big data (requiring big heaps).
‘Cloud and Virtualization: Multi Tenancy’ was the title of a slide talking about ‘dynamic scaling and on-demand availability,’ maintaining ‘full isolation’ and maximizing ‘resource utilization.’
The ‘Developer Experience: Continued Improvement’ slide referenced the value of multiple languages supported on the virtual machine. The slide and speaker also referenced improving the development experience with ‘dynamic development and debugging’ through ‘close cooperation with IDE developers.’
A JEP is a Java Enhancement Proposal and JEPs document via community process what is to be added to the virtual machine. It was stated in this session that the JVM can now be scaled from the small Raspberry Pi to the huge Exalogic T3-1B. The point was made that many of the things that benefit one of these extremes also benefit the opposite extreme and everything in between.
The ‘Footprint: Every byte counts!’ slide covered some examples of features of the embedded JVM that the HotSpot VM developers are working to add to the HotSpot VM. These include ‘compact JVM internal structures’ (JEP 147) and ‘dynamic sizing’ of ‘interned string table,’ ‘system dictionary,’ and ‘caches.’ Both enterprise and embedded extremes benefit from these changes.
In conjunction with the bullet ‘Java Heap is ‘Easy’,’ there was mention of HPROF and Java Mission Control. Native Memory Tracking is ‘really useful for hunting footprints in general.’
JSR 292/JEP 160 (invokedynamic had some issues (NoClassDefFoundError) in its initial release, but they believe these issues have been addressed. As was stated in The Road to Lambda earlier today, Project Lambda is using invokedynamic. The point was made that this is evidence that invokedynamic is not just for ‘alternate JVM languages,’ but is useful for the Java language itself. Project Nashorn will also benefit from invokedynamic.
Three actions were outlined that optimize for multiple languages. These are ‘inlining’ (all of which is done upfront today, but they’d like to enable compiler to incrementally inline), ‘escape analysis improvements’ (analysis of ways to improve code), and ‘boxing elimination’ (avoid extraneous object creation). JEP 165 deals with ‘fine-grained compiler control’ and JEP 143 exists to improve lock contention.
There was discussion of the slide ‘G1 – Garbage First: The Future of Garbage Collection.’ It was explained that this changes the approach from ‘one ginormous Java heap’ to heap treated as ‘many small parts.’ The -XX:+UseG1GC option was mentioned as a way to try out this new garbage collector as of JDK 7 Update 4. JEP 144 is designed to reduce garbage collection latency for large heaps.
‘PermGen is no more!’ is a bullet on the slide on the new JVM memory layout anjd is a result of JEP 122. This change is supposed to be ‘transparent to user,’ but they would like Java developers to try it out to make sure the change is truly invisible.
JEP 159 deals with ‘Enhanced Class Redefinition.’ They would like to relax today’s ‘redefinition using java.lang.instrument, JVMTI, etc.’ to more than just redefining code body.
Another direction for the JVM developers is toward heterogeneous computing. ‘GPUs are very powerful and more available than in the past.’ Project Sumatra attempts to support GPUs and Arrays 2.0 concept.
The point was made that ‘the Cloud makes the deployment environment more fluid,’ but that ‘the JVM is in a unique position to help.’ Their goal is to ensure that the JVM can pick up cloud-related changes and maintain isolation.
It was pointed out that ‘a nice outcome of the removal of the Permanent Generation’ is that ‘Class Data Sharing’ now can work with all garbage collectors rather than working only with the serial collector. JEP 145 aims to reduce start-up time and to reduce warm-up time of a Java application.
It was emphasized several times in this presentation that developers can help test out and drive fixes and improvements by downloading the latest versions of the VM and language compiler, trying them out, and providing feedback. The JDK8 early access builds are available for download and the versions without permanent generation should be available soon.
Don’t forget to share!
Reference: JavaOne 2012: Looking into the JVM Crystal Ball from our JCG partner Dustin Marx at the Inspired by Actual Events blog.
