zafena development

December 1, 2011

LLVM3.0 target feature matrix :

LLVM 3.0 have been released

LLVM includes the JIT that can be used to speed up OpenJDK on all platforms that currently only have support by the platform independent Zero C++ hotspot port.

The JIT in LLVM have been redesigned from the ground up to use the same code path ways as used by the static compilation in LLVM by using the new MCJIT that in turn are based on the new direct Machine Code emission back-end. LLVM will over time drop support for the old "classic" jello-JIT.

OpenJDK Shark + LLVM 3.0 patches exist on zero-dev

I have posted some LLVM 3.0 patches to zero-dev that allows OpenJDK Shark to be built using this new MCJIT. Grab them all at:

Builds and testers are needed for MIPS, PPC and ARM

Shark are known to work stable on X86 hardware where all parts of LLVM have great community support. For all other architectures please check out the LLVM Target Feature Matrix.

According to this Target Feature Matrix table, MIPS JIT support are now GREEN! MIPS devs should try the OpenJDK + Shark + LLVM 3.0 combination, it could turn out to be really good. If you have a spare MIPS machine that are online 24/7 do consider adding it to the LLVM and IcedTea buildbot network!

For ARM the MACH-o JIT backend are supposed to be working, testers of OpenJDK + Shark + LLVM 3.0 on darwin based platforms like the iPhone and iPad please step forward, this combination looks to be working, at least on paper.

All ARM Linux users have to wait until the ELF MCJIT are stable before we can expect to run Shark using LLVM 3.0 and later.

PPC testers are also needed, LLVM support for PPC have been 90% good in the past.. it could be all broken or all working, no-one really know at least the LLVM darwin PPC buildbot shows some green lights but we currently do not have any IcedTea PPC buildbots to check if Shark + PPC work at all.


  1. Greetings you should add x32 to the list the new linux ABI

    ive reworked the patch to be backward compat ...

    have not got it working just yet but willl

    Thanx / Regards


    Comment by Greg — February 8, 2013 @ 19:08

  2. Roman Kenkke is the new Shark maintainer who have merged all work mentioned here and recently got Shark working using LLVM 3.2+ and the new MCJIT on PPC64. I will forward the bug to Roman and check what needs to be done to add x32 Shark support.

    Comment by xerxes — February 8, 2013 @ 22:04

  3. Thank you yes i noticed also picked up the chattter on twatter when i looked at your patch set
    i mistakenly assumed removing a couple "const" and wrapping it in #if ... for backward compat would be trivial.... clearly not the case.

    x32 is rather intresting and we replacing our "distro" 32bit version with it and deprecating 32bit [i386] at the same time we releasing a ppc/arm flavor and possibly mips [they dont seem to have the right product].

    Java is not currently shipped on the distro the managment interface is a java applet but can be run standalone. the main motivation for adding java is to allow "techies" to launch the applet via a SSH/X connection.of course when we started Sun was not too friendly about distributing the JRE we did supply windows binaries with click through licence.

    Find llvm/shark intresting and saw this as a way to learn some new tricks.

    Thx for the work on this.

    Comment by Greg — February 9, 2013 @ 10:40

  4. When we port OpenJDK (Java) to new architectures we frequently overlook the need for developers to have a way to query the runtime in order to find out the ABI in use. This is especially true now when we got more than one ABI in use for each architecture.

    I have posted a solution for use by to end user Java applications on how to handle this ABI situation without relying on if the JVM Vendors have agreed on additions to the system properties namespace and if proper #JVM os.arch & ABI properties are set or not.

    Linux distributions themself usually misses to check this because they only thet the JVM in combination with Java software they have built by themself, software which native ABI is tuned to the JVM architecture by the distribution build system thus without having to think about doing proper ABI detection at runtime before loading the native JNI libraries with the correct ABI.

    Linux distributions do run into this ABI issue if they try to run Java applications from outside the distributions packages and when using multiarch, then the JVM will report too little information to the end user application and the application will guess and load the wrong ABI native JNI at runtime. - Because the ARM JVM still cant differensiate ABI in its system properties #JogAmp #Gluegen now implement an ELF header parser

    Comment by xerxes — February 10, 2013 @ 03:52

  5. Now, I going to build OpenJDK7 with Shark JIT with LLVM 3.0.
    (Ubuntu 12.04 64bit)

    1. install LLVM 3.0
    2. hg clone
    export SHARK_BUILD=true
    export ZERO_BUILD=true
    and make

    it's wrong with configure use SHARK?

    Work well when do not export SHARK_BUILD and ZERO_BUILD.

    Comment by Andy Kim — July 15, 2013 @ 08:45

  6. @Andy the sourcecode at is daily updated. Roman Kenkke did some work on it some months ago and updated it to use LLVM 3.2. Shark was functional around december 2012; Both LLVM and hotspot-comp sourcecode have evolved since then and now its back to non working state again, i am afraid. Read and help out at the zero-dev mailinglist if you want to help test and fix Shark!

    Comment by xerxes — August 3, 2013 @ 22:23

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress