I spent quite a lot of time tracking down a miscompilation in LLVM lately but I’m pretty much back on track now. One fun thing is that I figured out how to add diagnostic options to OpenJDK, so when I eventually release Shark you’ll be able to debug it with the following exciting options:

-XX:SharkStartAt=N
Start compiling only after N compilation requests. (Use in conjunction with -XX:+PrintCompilation.)
-XX:SharkStopAfter=N
Stop compiling after N compilation requests.
-XX:SharkDumpModuleAfter=N
Dump all generated LLVM bitcode (to hotspot.bc) after N compilation requests.
-XX:SharkPrintTypeflowAfter=N
Print the results of the typeflow pass of the Nth compilation request.
-XX:+SharkTraceBytecodes
Print the name and bci of each bytecode compiled (Handy for crashes).

I tend to use them in pairs, eg -XX:Shark{StartAt,DumpModuleAfter}=17.

This list will probably get real old real quick, but they’ll all be listed in ports/hotspot/src/share/vm/shark/shark_globals.hpp.

2 thoughts on “

  1. It looks like you are having a lot of fun building this. But, maybe you could get some faster using VMKit in LLVM. It already compiles JVM bytecodes to LLVM so you could focus instead in other areas.

    Just my Two Cents.

  2. Hi Martin, I checked out VMKit when I started looking into LLVM. The problem is that what we want is to be using HotSpot (with the eventual aim of passing the TCK) and VMKit is fundamentally an entirely different VM. The implementations of the simpler bytecodes could pretty much be copied and pasted, but stuff like aload_0 you could implement in under a minute anyway. The complex bytecodes, the ones that take the time, pretty much everything they do is completely different :/

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.