The return of the Shark, part II (howto)

So, finally, after some back and forth, the Shark fixes landed in hotspot-comp (thanks Twisti for reviewing and pushing me). It took a little while to sort out the new atomic operations in LLVM. If you want to play with it, you first need LLVM 3.2 (not the latest 3.1 release!):

svn co llvm-3.2
cd llvm-3.2
./configure && make && make install

Then you need to check out hotspot-comp:

cd ..
hg clone
cd hotspot-comp

Finally, I recommend you use my build script for Shark: place it in the toplevel directoy of hotspot-comp and modify all the env variables to your needs. Most importantly, change LLVM_CONFIG to point to your $LLVM_INSTALL_DIR/bin/llvm-config. Enjoy the Shark! 🙂

The return of the Shark

During the last couple of days, I’ve been working on fixing Shark for OpenJDK8. Shark is an awesome compiler backend for OpenJDK’s Hotspot JIT, originally written by Gary Benson. The idea is that, instead of generating target machine code dircetly, Shark would generate an intermediate representation (IR) for LLVM, and let LLVM’s JIT compiler generate the target machine code. The advantage being that it’s much easier to port to new platforms than writing your own C1 and/or C2 compiler for HotSpot. Unfortunately, Gary left Red Hat’s Java team a while ago which basically left Shark unmaintained. In the time since, several significant changes happened both in HotSpot and LLVM. After having fixed Zero for OpenJDK8 I thought I’d give Shark a try and spend a little time on it. The most problematic changes in LLVM or Hotspot have been:

  • Hotspot’s internal oop class hierarchy has been split into two: oops (all objects) and metadata (classes, methods, etc). This caused some major headaches because Shark code was basically assuming everything’s an object, and it was not always clear what actually to use: a Klass* or its Java mirror (basically an instance of java_lang_Class)? Etc etc.
  • A bunch of intrinsics for atomic operations (compare-swap, memory barrier, etc) have been remove from LLVM, and in their place now is a direct representation in the IR. Which actually makes it much nicer and easier to use in Shark.
  • Several smaller little things, to many and probably to little to list here.

With this, I can now do a full build of OpenJDK/Shark on x86, which I am quite proud of. It’s already successfully running a lot of code, but at the same time I am still hitting some bugs. After I have ironed them out I will propose the changes for inclusion in OpenJDK8 of course.