The return of the Shark
November 20, 2012 4 Comments
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.