Disassemble Java JIT compiled native bytecode_问答_开发者

Is there any way to do an assembly dump of the native code generated by the Java just-in-time compiler?

And a related question: Is there any 开发者_StackOverflowway to use the JIT compiler without running the JVM to compile my code into native machine code?

Yes, there is a way to print the generated native code (requires OpenJDK 7).

No, there is no way to compile your Java bytecode to native code using the JDK's JIT and save it as a native executable.

Even if this were possible, it would probably not as useful as you think. The JVM does some very sophisticated optimizations, and it can even de-optimize code on the fly if necessary. In other words, it's not as simple as the JIT compiles your code to native machine language, and then that native machine language will remain unchanged while the program is running. Also, this would not let you make a native executable that is independent of the JVM and runtime library.

If Amigable Clark Kant thought your question was heresy, he will really flip out over this answer. File this under "what is possible" not necessarily under "Justin recommends". :-)

One option is to use IKVM.NET to process your Java code using Mono. IKVM.NET allows you to run Java code on top of .NET or the Mono CLR. Some might say that you are skipping the JVM this way although it would be more accurate to say that IKVM.NET is really an implementation of the JVM that runs on the CLR.

At any rate, if you do this, you now have the option of doing Ahead-of-time (AOT) compilation of your code with Mono. That is, you can compile your code all the way down to machine native which means that you do not need either the CLR or the JVM at runtime.

Unlike what Jesper says above, using AOT compilation can actually result in better performance. While it is true that the JVM (and the CLR) perform some optimizations at runtime that are not possible at compile time, the reverse is also true. Also, one of the options is to use LLVM for code generation which typically results in better performance.

Here is the pipeline in a nutshell:

Your code -> IKVM.NET -> Mono -> LLVM -> Native executable

Or, just use a Java compiler that is designed to AOT generate native executables from the start (like GCJ or Excelsior Jet).

One place that the Mono/IKVM.NET option might be useful is if you want to use a Java library as part of an iPhone app (using MonoTouch). The App Store only allows native binaries.

EDIT: You can also use the LLVM VMKit to AOT compile Java code to machine code. This is conceptually the same process I described with Mono but keeping that nasty CIL stuff out of the picture.

You can't use the JIT to produce a standalone executable, you'd need some other system like GCJ. As far as seeing the JIT generated code, check out the OpenJDK source to look for debugging options. You can build your own copy with those enabled and see what the JIT is doing, or add your own enhancements to output whatever you like.

Check out the Oracle Solaris Studio Performance Analyzer. I saw Charlie Hunt demo it at a conference, and it was simply breathtaking. It lets you do runtime debugging and disassembly of Java applications, i.e. view the machine instructions with hotspots actually highlighted. See also this book excerpt: http://charliehunt.ulitzer.com/node/2067673

More documentation: Oracle Solaris Studio 12.2: Performance Analyzer

Yea I was also thinking it would be hard to obtain JIT native output but this guys paper keeps showing native code but doesn't say how he got the output. I can understand if the output from the JIT compiler would be inconsistent as it will change from time to time or get purged from the code cache only to be regenerated later on but how do you get a quick snapshot of some assembly for some code blocks. :|

http://www.google.com/url?sa=t&rct=j&q=Java+annotation+for+optimization&source=web&cd=15&ved=0CKEBEBYwDg&url=http%3A%2F%2Floome.cs.uiuc.edu%2Fpubs%2Fjones-kamin.pdf&ei=8vj-UN63C-bQ2QX-9IDoDQ&usg=AFQjCNEegMNXLwKyUTTJ5ljgnP7X9rPXHg&bvm=bv.41248874,d.b2I