PrintCompilation JVM flag

While doing some performance checking on ThreeTen/JSR-310 I tried using the -XX:+PrintCompilation flag. In doing so, I discovered a certain lack of documentation due to a key Sun blog no longer being available. This blog mostly exists to recover that information from the internet archive.

The PrintCompilation flag exists to show basic information on when Hotspot compiles methods. Moazam Rajas wrote about the output format in his Sun blog, which was ported to Oracle. Unfortunately, only part of the original article was ported, losing the vital part. The internet archive appears to have the key part of original document:

But nevertheless, lets get back to the meat of the matter, the question on -XX:+PrintCompilation. I thought that a more detailed explanation of this flags output existed somewhere on the public internet, but maybe I just can't find it today. So I'll make a small attempt to explain the output.

The -XX:+PrintCompilation flag output looks something like this:

1  sb   java.lang.ClassLoader::loadClassInternal  (6 bytes) 	
2  b    java.lang.String::lastIndexOf  (12 bytes)
3  s!b  java.lang.ClassLoader::loadClass  (58 bytes)

Flags correspond to:

b    Blocking compiler (always set for client)	
*    Generating a native wrapper	
%    On stack replacement	
!    Method has exception handlers	
s    Synchronized method	

As Rajiv points on, once you find the offending method, you can tell the JVM to bypass it by creating a .hotspot_compiler file in your current working directory with an exclude statement. For example,

exclude java/lang/String indexOf

This would stop the java.lang.String.indexOf() method from being compiled.

Two other messages that appear are "made not entrant" and "made zombie". Again, finding out what they mean isn't easy, however an OTN forum discussion has a link to a comment by Cliff Click:

Zombie methods are methods whose code has been made invalid by class loading. Generally the server compiler makes aggressive inlining decisions of non-final methods. As long as the inlined method is never overridden the code is correct. When a subclass is loaded and the method overridden, the compiled code is broken for all future calls to it. The code gets declared "not entrant" (no future callers to the broken code), but sometimes existing callers can keep using the code. In the case of inlining, that's not good enough; existing callers' stack frames are "deoptimized" when they return to the code from nested calls (or just if they are running in the code). When no more stack frames hold PC's into the broken code it's declared a "zombie" - ready for removal once the GC gets around to it.

So, here is my updated table of flags:

b    Blocking compiler (always set for client)
*    Generating a native wrapper
%    On stack replacement (where the compiled code is running)
!    Method has exception handlers
s    Method declared as synchronized
n    Method declared as native
made non entrant    compilation was wrong/incomplete, no future callers will use this version
made zombie         code is not in use and ready for GC

If you've discovered anything else about -XX:+PrintCompilation then please add a comment!

Update 2011-09-26:
Kris Mok has done lots of investigation of the flag in far more detail than I have. Please read his notes which are very comprehensive and by JDK version!

Premium JVM thoughts & Open JVM proposal

Some thoughts on the Premium JVM and the benefits of freeing the JVM separate from Java SE.

Premium JVM

The JVM is a technology we sometimes forget to talk about, yet it is central to development on the Java platform. Like most other Java technologies, it has a JSR - #924

Clearly, all the other languages on the JVM - Fantom, Groovy, JRuby, Clojure, Scala ... - all rely on the JVM primarily. Each of them also rely on the Java libraries to some degree, but the JVM is their core, and many of them would like to only depend on the JVM in an ideal world.

At QCon San Francisco, it is reported that Adam Messinger announced in passing that there would be a premium version of the JVM alongside the gratis (free) version. This raises many questions:

• Will the premium and gratis version be released at the same time?
• Will gratis version still support the same range of operating systems?
• What extra features will the premium version have?
• Is this only management features?
• Or are there performance features?
• Who is the target market?

My concern is that once you have the split, there will be a product manager for the premium version. Their bottom line and job success will depend on moving people from gratis to paid. They will therefore lobby against adding to the gratis version and rachet up the cost of the paid version.

Logically, this is just an extension of the JRockit product and shouldn't be a threat. Lets hope that the answers to the above are suitable and provided soon so the community has reassurance.

Update 8th Nov: This Oracle press release from September 2010 indicates the underlying situation - that "premium" simply refers to a continuation of the JRockit paid for elements. I still hope that more detailed information can be provided.

Oracle is currently working to merge the Oracle Java HotSpot Java Virtual Machine (JVM) and the Oracle JRockit JVM into a converged offering that leverages the best features of each of these market-leading implementations. Oracle plans to contribute the results of the combined Oracle Java HotSpot and Oracle JRockit JVMs to the OpenJDK project. The Oracle JDK and Java Runtime Environment (JRE) will continue to be available as free downloads, with no changes to the existing licensing models. Premium offerings such as JRockit Mission Control, JRockit Real Time, Java for Business and Enterprise Support will continue to be made available for an additional charge.

Update 10th Nov: This further update from Oracle provides a public HTML summary of what was announced at JavaOne. I understand this should be considered to be the definitive word on the strategy, and effectively confirms that the "premium JVM" name is just the continuation of those parts of JRockit that were already paid for.

Open JVM

Since the recent news that Oracle will not allow Apache Harmony to complete as an implementation of Java SE, I've noticed a number of tweets and blogs questioning the whole JVM platform, not just Java.

There are now people considering moving to the .NET CLR or other platforms away from the JVM. This cannot be a good thing for Oracle!

As Oracle have stated, the community cannot have an open standard for the Java SE platform. If we accept that (and given the history and legalities we shouldn't) then what is the next best thing?

What if there was an open standard for the JVM?

The JSR exists - 924. All Oracle needs to do is allow it to be freely implemented, without Field Of Use or any other limitation, and independently of the rest of Java SE (which I don't believe is possible at the moment).

Update: I asked for clarification from Henrik Stahl of Oracle. He replied to me by email giving me permission to reproduce this here:

Stephen, You asked me if it was possible to implement a JVM without Java. I looked into it and there seems to be technical showstoppers. The JVM specification was clearly written with Java in mind. There are dependencies in the spec on java.* classes such as Object, ClassLoader and various exceptions. A JVM cannot be implemented according to the spec without these classes. So it's not possible for you to implement a JVM without *some* Java. And if you have *some* Java you probably have to implement *all* of Java, since subsets are discouraged due to fragmentation concerns. (Disclaimer: I'm no lawyer. This is my personal interpretation, and is not an official Oracle position.)"

I don't see this as threatening to Oracle in the same way as Java SE is (at least not threatening technically - politically its always hard to tell). The JVM is a simple input/output machine, theoretically easy to test for compatibility independent of the rest of Java SE (please contradict me in the comments if you have additional knowledge here).

Making this available has huge benefits: It is a good PR move, softening the tension in the Java community. It allows part of Apache Harmony to be released properly. It ensures true competition in JVM performance and additional features in the same way as Java EE has benefitted. It also removes any lingering concerns that the gratis/premium version of the JVM could be abused.

I've always thought that Sun missed a huge trick in not getting the JVM adopted as the heart of language programming in all browsers. Technically, Javascript could run on top of the JVM embedded within the browser. Sounds odd? Well not if the JVM were a freely implementable specification without restriction, capable of being extended, tweaked and integrated in different ways.

For example, a JVM could be written that is more modular, or slimline more suitable for different environments, such as one designed explicitly for a world where Javascript was the primary language it ran. Or a JVM could be implemented directly on top of the CLR or LLVM, or integrated within. Or a JVM could even implemented in another language like Ruby or Javascript rather than C (I remember seeing this once, so its technically possible!).

There is a huge set of opportunities here!

And for Oracle, that would mean embedding the JVM bytecode definition at the heart of many more areas. Which would reconfirm the JVM as the core technology today.

Hey, if browser vendors adopted it, we could write real code in the browser instead of pesky Javascript! Which would surely be a better technical solution than cross compiling JavaFX down to Javascript.

Summary

The premium JVM concept should just be JRockit continued. But, given recent actions by Oracle, there has to be concern that its the first move to charging for the "real" JVM. Clarification is needed. Update: see above

One way to turn the situation around would be to make the JVM freely implementable separate from Java SE. Apache Harmony would benefit, lessing tensions, but so would many other environments. A JVM implemented using the CLR or LLVM would be immensely useful. And maybe, just maybe, we could get to write real code in browsers on a multi-platform VM instead of Javascript.

Stephen Colebourne
Apache Software Foundation member, speaking personally
Oracle Java Champion, speaking personally
Not a committer on Harmony or OpenJDK