zafena development

November 11, 2012

2008: Sun Microsystems invested heavily into using hardware acceleration on mobile devices using JOGL. This was the foundation to get JavaFX 1.3 running across devices. Video of James Gosling, Ken Russell and Sven Gothel on stage at JavaOne 2008 keynote
Ken Russel later wrote his last Sun blog-post that covers the technology demonstrated in this first OpenGL ES 2 JOGL demonstration:
Later during the same year Sven Gothel demonstrated hardware accelerated OpenMAX video decoding on the same Tegra 1 mobile device using the new re-architectured JOGL 2 with stellar mobile support:

2009: The core members of the JOGL and Java3D team left Sun before Oracle took over and forked JOGL.,21516.0.html

2010: The JogAmp community was created.

2011: Oracle Gives up on Java3D (and JOGL) for RIA (Webstart and Applets)
The Oracle decision to remove all signed Java3D and JOGL builds from their servers, and hence break all existing online Java3D/JOGL applications using the SUN/Oracle builds, this have only been mentioned by Oracle inside the support forum.
Fortunately JOGL and Java3D was originally released under a BSD license so it was possible for the community to keep-on maintaining the bindings and provide JogAmp signed builds.

2012: Oracle work on flushing out its own use of JOGL in JavaFX by removing jogl-prism. Oracle no longer give programmers direct access to OpenGL using their APIs.
Oracle announced during JavaOne 2012 that Oracle would like to get help from the community to port JavaFX to new platforms under the OpenJFX project. Surely the community can help by re-implement jogl-prism and adding raw JOGL support into OpenJFX to ease future OpenJFX porting efforts.

JOGL v2 is actively maintained by the JogAmp community.

JOGL v2 now runs on the latest GPU cores and work on top of any JVM. JOGL v2 contains its own platform independent NEWT windowing toolkit. NEWT applications targeting the GL2ES2 or GL2ES1 profile, both using a common subset of OpenGL and ES calls, can be deployed across different platforms and devices from desktop to mobile without code change. – Documentation, slides, and videorecording from the latest live JogAmp demonstrations

Java3D is now also maintained by some members of the JogAmp community.
hharrison now maintain Java3D on github
Julien Gouesse: Java 3D est de retour [Java 3D is back]

August 28, 2012

Last week I stumbled across and dipped my toes into, Avian, a new small and fast JVM that included a JIT for ARM.
Avian have been developed in the open during the last 5 years, I was quite surprised that all this was for me unheard of!
Avian got support to be used in combination with the OpenJDK 7 class library’s:

Build instructions to build Avian on a Raspberry Pi running Raspbian.
sudo apt-get install openjdk-7-jdk libz-dev git

# you may change these two export to match your system
# use i386, x86_64, armhf, armel or ppc here
export ARCH=armhf
# use i386, x86_64, ppc or arm here
export JVM_ARCH=arm

# clone and build avian in combination with one existing OpenJDK 7 jdk image
# It takes about 40 minutes to perform this compilation natively on a Raspberry Pi.
git clone
cd avian
JAVA_HOME=/usr/lib/jvm/java-7-openjdk-${ARCH} make openjdk=/usr/lib/jvm/java-7-openjdk-${ARCH}

# Run the avian test suite to check that your newly built avian pass all expected functionality
JAVA_HOME=/usr/lib/jvm/java-7-openjdk-armhf/ make openjdk=/usr/lib/jvm/java-7-openjdk-armhf/ test

# Install the built avian into OpenJDK 7
sudo mkdir -p /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian
sudo cp build/linux-${JVM_ARCH}-openjdk/ /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian
# Add -avian KNOWN to the end of the jvm.cfg file in order to make java -avian work
sudo sh -c "echo '-avian KNOWN' >> /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/jvm.cfg"

# hack for ubuntu and debian to let openjdk find the
sudo ln -s /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian/ /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/
# the hack/workaround is required if you see the following error when running java -avian -version
# Error: Could not create the Java Virtual Machine.
# Error: A fatal exception has occurred. Program will exit.
# The above hack is not required if you compile your own build of IcedTea or OpenJDK from upstream source directly

# Done now try run it
java -avian -version
# The output to be seen
java version "1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1) (7~u3-2.1.1-1+rpi1)
Avian (build null, null)

Avian is heavily tested by its main developers for use running Eclipse SWT applications,
users of Avian have only had working Swing and AWT running during this last month.
expect Java2D to still be a little shaky when using Avian, I expect these Java2D issues to stabilize quickly thanks to the rapid development cycle that takes pace on git hub and thanks to the internal Avian test-suite that gets run after each build.

Avian got some interesting properties:
The JIT is good, it runs at a speed similar to CACAO JIT and the Thumb 2 JIT add-on for Zero.
It is embeddable, you may use Avian to create a small standalone executable that include both the JVM and your application, Avian then uses proguard to cut out and bundle only the needed code from the large OpenJDK class library that is required to run your application, all documented in the avian build documentation. This embeddable feature would possibly allow, free and open-source, OpenJDK applications to be deployed inside walled gardens such as mobile platform application stores, some people even got it to run on webOS. Avian makes Java viable on low footprint embedded systems, a generated standalone executable can be compressed to less than 1Mb!

August 22, 2012

Your CPU is inefficient to render graphics on large displays:

For a long time computer programs and operating systems have been updating the display memory directly using the main CPU. Many high level programming languages was able to draw graphics faster by simply optimizing the internal JIT compiler that allowed the graphics routines to run faster on the CPU. This simple approach was fine when computers got relatively small screens of less than 640×480 pixels the code running on the CPU was then able to update all the 307 200 pixels on the screen using only a couple of Mhz processing time, if you wanted 60 updates per second then your CPU had to update 640*480*60 ≃ 18Million pixels each second, each pixel is made up red, green and blue stored in four bytes on a 32bit display thus 18Million * 4 = 72Million bytes to get updated each second, this was almost still possible to do on a 200Mhz CPU since you then had some time left to do general computations.

When you attached larger pixel density displays then the work load increase, a full HD display at 1980×1080 require that your CPU would need to update 1980*1080*60*4 ≃ 5000Million bytes/second you would then need a 10Ghz CPU to perform this task.. this kind of CPU is impossible to create, it would self-combust, since it require enormous amounts of power because the power consumption and generated heat by the CPU increases exponentially with the increased clock rate.

During the work of porting OpenJDK to run on ARM CPUs a lot of effort went into optimize the JVM to speed up basic computations, this work did also speed up graphics rendering to some degree using a JIT yet we faced a wall. The main bottleneck was limited that we only tried to use the main CPU. I had to find a way to offload graphics tasks from the main CPU to the graphics GPU processor found in the ARM, system on a chip, SoC designs to get good and fluid graphics performance using OpenJDK.

Modern graphics GPUs are designed to render graphics large screens using the least amount of energy:

A modern graphics GPU solves the problem on how to update the large displays by using the least amount of energy by using parallelism at the hardware level, the GPU is made up of several small processor-cores running at a lower clock rate that can receive instructions from the main CPU. The many smaller GPU cores can operate in parallel to quickly update the large screen. The main CPUs task is now changed from updating the graphics memory pixels directly to become a command central with the main purpose to inform the many GPU hardware cores what to do. Luckily the graphics GPU vendors have agreed on a standardised way on how to let applications running on the main CPU to interact and instruct the graphics GPU. The GPU vendors let you access the GPU by using the OpenGL “c” API. OpenGL is accessible by loading a shared library, libGL or libEGL, shipped with your operating-system.

Unfortunately high level languages running on the JVM can not use the system installed libGL or libEGL directly, they require a bridge usually coded in the JNI API to get access to the system OpenGL library. Writing JNI code manually to simply forward all OpenGL library calls would be high maintenance work and error prone.

I did check if there was any existing bindings found buried inside the OpenJDK Java2D classes and yes it did contain an old backend for desktop OpenGL 1 to let Swing and AWT applications run accelerated, unfortunately this backend had not been maintained for many years and was not even enabled by default, instead all Java2D was rendered using the CPU directly, you can enable this OpenGL 1 backend by passing -Dsun.java2d.opengl=True . The existing OpenGL 1 Java2D bindings contained no code to let applications access the most recent OpenGL 2 and OpenGL ES 2 hardware, I had to look elsewhere for a suitable binding to get access to accelerate graphics using the OpenGL ES 2 GPU found inside ARM SoCs.

JogAmp solves the problem on how to get access to your fast GPU to perform rendering from high level languages running on the JVM like Java:

I have worked with the JogAmp community that provide a platform neutral binding that allows languages running on the JVM a low overhead access to the system installed OpenGL library. JogAmp JOGL uses a tool called gluegen to load and probe the system installed libGL and libEGL at runtime and is able to auto-generate the required JNI code and classes to let languages running on the JVM get a low overhead direct access to the OpenGL API!

I have published a small JogAmp JOGL OpenGL ES 2.0 Vertex and Fragment shader introduction, that demonstrates how to access OpenGL 2/ES 2 from Java using JogAmp JOGL at:

The nice thing about this introduction is that the demo source and the compiled java .class will run unmodified on both Desktop OpenGL GL2 systems and Mobile OpenGL ES2 systems.
It uses the JogAmp GL2ES2 GLProfile that use the common subset of OpenGL calls found in both desktop GL2 and mobile ES2. JogAmp will handle all platform specific bits for you like how to open a native drawable surface and let your application focus on rendering using the platform independent OpenGL/ES calls. Note that the demo source-code itself contains no Architecture or OS specific code at all!

Demo break… lets have some fun…

Try the demo on a java enabled Desktop/Mobile running X11/Windows/MeeGo or Mac system:

7z x jogamp-all-platforms.7z
cd jogamp-all-platforms
mkdir -p demos/es2
cd demos/es2
cd ../..
javac -cp jar/jogl-all.jar:jar/gluegen-rt.jar demos/es2/
java -cp jar/jogl-all.jar:jar/gluegen-rt.jar:. demos.es2.RawGL2ES2demo

Raspberry Pi supported!

At Siggraph 2012 i demonstrated for the first time JogAmp JOGL OpenGL ES 2 bindings running on the RaspberryPi, since then all source-code have been committed to the JogAmp JOGL git and been processed through the JogAmp “chuck” auto-builder. Raspberry Pi is supported by the current JogAmp release thus use the same instructions to compile and run as compared to desktop! The Raspberry Pi Broadcom VC IV NEWT driver is included.
I am personally *stunned* by the excellent performance you get on the small Raspberry Pi machine, at 5-watt power consumption, it runs butter-smooth and outclass my desktop Intel Q45/Q43 Chipset system when running at full HD 1980×1080 resolution.

I hope you enjoyed the demo.

Lets talk about the shader programs that got executed inside your graphics GPU:

The only way to create a program that can get run and executed on the GPU is by transmitting shader code to the GPU through the OpenGL 2 API.

The shader program itself is sent as a clear text string to your GPU driver for compilation. When the program is compiled OpenGL hands you a reference to the program in form of a number-ticket that you later on can use to activate the program. You will not be able to actually see the compiled code, what the compiled program looks like is still a secret only known by your GPU vendor.

The opengl API let you define two types of GPU programs, a vertex shader and a fragment shader:

The vertex shader gets executed one time for each vertex:

/* Introducing the OpenGL ES 2 Vertex shader
 * The main loop inside the vertex shader gets executed
 * one time for each vertex.
 *      vertex -> *       uniform data -> mat4 projection = ( 1, 0, 0, 0,
 *      (0,1,0)  / \                                          0, 1, 0, 0,
 *              / . \  <- origo (0,0,0)                       0, 0, 1, 0,
 *             /     \                                        0, 0,-1, 1 );
 *  vertex -> *-------* <- vertex
 *  (-1,-1,0)             (1,-1,0) <- attribute data can be used
 *                        (0, 0,1)    for color, position, normals etc.
 * The vertex shader recive input data in form of
 * "uniform" data that are common to all vertex
 * and
 * "attribute" data that are individual to each vertex.
 * One vertex can have several "attribute" data sources enabled.
 * The vertex shader produce output used by the fragment shader.
 * gl_Position are expected to get set to the final vertex position.
 * You can also send additional user defined
 * "varying" data to the fragment shader.
 * Model Translate, Scale and Rotate are done here by matrix-multiplying a
 * projection matrix against each vertex position.
 * The whole vertex shader program are a String containing GLSL ES language
 * sent to the GPU driver for compilation.
static final String vertexShader =
// For GLSL 1 and 1.1 code i highly recomend to not include a 
// GLSL ES language #version line, GLSL ES section 3.4
// Many GPU drivers refuse to compile the shader if #version is different from
// the drivers internal GLSL version.
"#ifdef GL_ES \n" +
"precision mediump float; \n" + // Precision Qualifiers
"precision mediump int; \n" +   // GLSL ES section 4.5.2
"#endif \n" +

"uniform mat4    uniform_Projection; \n" + // Incomming data used by
"attribute vec4  attribute_Position; \n" + // the vertex shader
"attribute vec4  attribute_Color; \n" +    // uniform and attributes

"varying vec4    varying_Color; \n" + // Outgoing varying data
                                      // sent to the fragment shader
"void main(void) \n" +
"{ \n" +
"  varying_Color = attribute_Color; \n" +
"  gl_Position = uniform_Projection * attribute_Position; \n" +
"} ";

The fragment shader gets executed one time for each visible pixel fragment:

/* Introducing the OpenGL ES 2 Fragment shader
 * The main loop of the fragment shader gets executed for each visible
 * pixel fragment on the render buffer.
 *       vertex-> *
 *      (0,1,-1) /f\
 *              /ffF\ <- This fragment F gl_FragCoord get interpolated
 *             /fffff\                   to (0.25,0.25,-1) based on the
 *   vertex-> *fffffff* <-vertex         three vertex gl_Position.
 *  (-1,-1,-1)           (1,-1,-1)
 * All incomming "varying" and gl_FragCoord data to the fragment shader
 * gets interpolated based on the vertex positions.
 * The fragment shader produce and store the final color data output into
 * gl_FragColor.
 * Is up to you to set the final colors and calculate lightning here based on
 * supplied position, color and normal data.
 * The whole fragment shader program are a String containing GLSL ES language
 * sent to the GPU driver for compilation.
static final String fragmentShader =
"#ifdef GL_ES \n" +
"precision mediump float; \n" +
"precision mediump int; \n" +
"#endif \n" +

"varying   vec4    varying_Color; \n" + //incomming varying data to the
                                        //frament shader
                                        //sent from the vertex shader
"void main (void) \n" +
"{ \n" +
"  gl_FragColor = varying_Color; \n" +
"} ";

Use the source!
When you first look at the source code you might find the many lines needed to render a single triangle scary.
Take a break and instead focus on the display function that gets executed about 60times/s here notice that the CPU only have to perform a handful of 4x4 matrix multiplications and then call about 15 function calls to pass all data information to the vertex and fragment shader programs inside the GPU. The GPU then by itself performing all rendering to the screen. This small amount of preparation done by the CPU each frame can easily be performed by the most simple JVM interpreter. The main bottleneck is gone we have successfully offloaded all the time consuming graphics rendering from the CPU to the GPU and as a bonus we find that we got a lot of free idle CPU time to perform general application logic computations on the JVM.

Edit: For game programming we recommend you to use JogAmp indirect through a game engine library such as libgdx or jMonkeyEngine3. We have a forum thread inside the JogAmp community where we work on improving engine support for Raspberry Pi using said engines. By using a game engine will get you up to speed developing professional games that is utilizing the hardware acceleration across devices!

Edit2: New JogAmp video/teaser footage is now online for the FOSDEM 2013 talk and the Siggraph 2012 BOF to get a better idea on what is possible to using JogAmp in combination with engines across devices. You may want to read the post that include background information on the FOSDEM 2013 demo setup.

I hope this introduction have been a delight to read, cheers and have a great day!

July 30, 2012

Robert Lougher have updated JamVM to work on the new Raspberry PI armhf “Raspbian” image, thank you Robert! You can compile and test this latest JamVM version from source on a Raspberry PI by running the following lines inside a terminal:

sudo apt-get install openjdk-6-jdk git libtool autoconf automake

git clone git:// jamvm

cd jamvm

./ –with-java-runtime-library=openjdk6


mkdir /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jamvm

sudo cp src/.libs/ /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jamvm/

sudo sed -i ‘s#-jamvm ERROR#-jamvm KNOWN#’ /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jvm.cfg

java -jamvm -version

java version “1.6.0_24″OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-2+rpi1)

JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)

I have update IcedTea6 1.12 and IcedTea7 2.3 release branches to include this updated version of JamVM. Distributions like Debian/Fedora/Ubuntu/Arch and Raspbian will get this new work when they update IcedTea to include the next IcedTea release or security update. This is the first JamVM + OpenJDK update in 2012, this update also include support for JamVM to run the QT-Jambi GUI toolkit.

February 27, 2012

Today JogAmp added a workaround to deal with GPU drivers that reports a bogus 0Hz screen refresh rate. With this fix in place hardware acceleration are working out of the box on Nokia N9 MeeGo phones in combination with the Nokia compiled Imaginative Technologies SGX 530 GPU drivers!

If you have OpenJDK installed on any ARMv7 board with a proper OpenGL-ES libEGL and libGLES driver setup then you can try running this for yourself by using my prebuilt jogamp-armv7 jars.


tar zxvf jogamp-armv7.tar.gz

cd jogamp

sh ./

Source and build instructions are available.

JogAmp JOGL OpenGL-ES Driver compatiblity matrix

I am tracking ARMv7 libEGL/libGLES* GPU drivers compatiblity with JogAmp here:

Chuck Norris force you to use the produced jars from the JogAmp “Chuck Norris” build-bot! uses gluegen build 510

Assemble a ARMv7 jogamp testfolder using the JogAmp daily build:



7z x gluegen-2.0-b510-20120225-linux-armv7.7z

7z x jogl-2.0-b684-20120227-linux-armv7.7z

mkdir -p jogamp/jar
cp -r jogl*/etc jogamp/etc/
cp gluegen*/jar/*.jar jogamp/jar
cp gluegen*/lib/* jogamp/jar
cp jogl*/jar/*.jar jogamp/jar
cp jogl*/lib/lib* jogamp/jar
cp /usr/share/java/hamcrest-core.jar jogamp/
cp /usr/share/java/junit4.jar jogamp/

cd jogamp

java -cp jar/gluegen.jar:jar/jogl.all-mobile.jar:jar/jogl.test.jar:hamcrest-core.jar:junit4.jar com/jogamp/opengl/test/junit/jogl/demos/es2/newt/TestGearsES2NEWT -time 40000


February 25, 2012

I have created a Twitter stream where I track my current progress on getting desktop OpenJDK applications running faster on ARM by taking advantage of the OpenGL ES, possibly in combination with the lima driver, and OpenVG hardware acceleration.

OpenJDK  currently fallback to used CPU bound software rendering to draw most of Java2D and 3D application on ARM.

I decided to look into it and noticed that OpenJDK internally currently only support fast hardware acceleration on GNU/Linux systems by using the standard libGL OpenGL library, this libGL library do not support the latest ARM system on a chip GPU designs instead it allways fallback to use the uttelry slow Mesa software rasterizer. In order to get things fast OpenJDK need to take controll of the ARM GPU’s using the libEGL and libGLES* OpenGL ES library drivers.

You can get OpenJDK running 2x faster today by simply setting:


This will enable the xrender pipeline made by Clemens, its compiled in most OpenJDK builds and are simply waiting for you to switch it on to test it, its not as fast as the libEGL drivers but its faster than the pure software rendered X11 pipeline. 🙂

I expect to get OpenJDK running butter smooth when proper hardware acceleration using JogAmp or LWJGL are in place, both of these API have recently added OpenGL ES support in the latest releases. A promising candidate to make it happen are to combine the JogAmp JOGL OpenGL ES bindings with Brandon Borkholder’s GLG2D.!/xranby -Tweeets for you!

February 15, 2012

Jim Connors at Oracle posed a interesting valentines gift, a compare of the latest open-source OpenJDK ARM JVM inside IcedTea6, 1.12pre, HEAD against their closed source Hotspot c1 and c2 implementations.

The Oracle blog antispam system in use...

I would have liked to comment directly on your blog but your spam system kept me at bay so i posed my reply to you here instead 😉

The OpenJDK Zero *mixed-mode* JVM used in Jims compare includes the now re-maintained ARM Thumb2 JIT and assembler interpreter port that got re-introduced in the IcedTea6-1.11 release.
Many of the OpenJDK JVM like CACAO and JamVM are by design tuned for embedded and client use and thus show strength in both low memory overhead and fast startup time.

When testing JVM performance on ARM its important to remember that the default optimization settings used by the compilers to build the JVM do matter.

The Debian 6.0.4 squeeze “armel” distribution use ARMv4t optimization by default. This low optimization level enable the Debian built packages run on as many kind of different ARM broads and CPU’s as possible. The trade-off are that you basically disable all VFP, floating point, optimizations and make synchronization code slower by forcing the JVM to call the Linux kernel helper instead of using faster ARMv7 atomic instructions directly.

To give OpenJDK JVM a better match i would suggest re-running the benchmark using OpenJDK built on top of Debian wheezy “armhf”, Ubuntu Precise “armhf” or Fedora F15 that by default optimize for the ARMv7 thumb2 instruction-set and make use of the VFP unit inside the CPU, also the “armhf” ABI allows better argument passing between library functions inside the CPU VFP registers. Two OpenJDK JVM, JamVM and Zero,  are already updated to support the new “armhf” hardfloat ABI.

You could also choose to run this benchmark using OpenJDK JVMs built using the Ubuntu Precise “armel” tool-chains that still use the legacy soft-float ABI while still adding ARMv7 Thumb2 and VFP optimizations. All OpenJDK JVM tested in this compare would run better by simply using a higher optimization level during the build.

All in all thank you Jim to give an introduction to the ARM OpenJDK porting effort, I look forward to the follow up article where all the JVM makers have picked their favourite GCC/Clang/Foo compiler options and suitable matching compile flags. One idea are to create a OpenJDK binary release with a custom OpenJDK installer that would ease testing of tuned OpenJDK JVM implementations.

Cheers, Xerxes

January 11, 2012

The brand new Tizen SDK got released

Tizen are a new mobile platform with the aim to thrive in a new ecosystem made up of HTML5 and js based applications.

The Tizen SDK includes the Eclipse IDE and an emulator themed after Samsungs new atom-phone reference design. The emulator come pre-installed with a functional Tizen phone system and some sample applications.

Booting up Tizen

The emulator can get started from the Tizen Emulator Manager. I can then connecting to it by running

sdb shell

Under the hood we can find a small Debian GNU/Linux root filsystem, an Xorg server, pulseaudio and many other nice system services just like on regular Linux desktop. This are good because it will enable us to quickly add some new software stacks to Tizen!

OpenJDK on Tizen

After a quick sdb push i had uploaded a pre-built OpenJDK-6 image running the LLVM 3.0 based Shark VM into Tizen and behold: oneslime on Tizen 🙂

Thank you Linux foundation for pushing GNU/Linux into mobile phones!


Summary: OpenJDK work fine on Tizen and the Tizen SDK work fine using OpenJDK!

December 2, 2011

I have been following the CACAO JVM development on ARM since 2008, back then CACAO was one of the first alternative JVM, to be used instead of Hotspot in combination with the OpenJDK 6 class libraries.

CACAO history dates back to 1997-1998 when CACAO was one of the first JIT compiler to be used instead of SUN’s Java JVM interpreter.

Today CACAO are being used in combination with OpenJDK 6 on architectures like ARM, MIPS and PPC where Oracle have not yet released code for a GPL licensed Hotspot JIT. CACAO are popular, see the Debian OpenJDK-6 popularity contest chart where up to 80% of all the Debian OpenJDK 6 JVM users have picked CACAO to be installed. This trend kept on since the beginning of 2009 up to the summer of 2011.

Carpe diem CACAO JVM!

During the summer of 2011 Oracle released OpenJDK 7 and CACAO users started to abandon the JVM in favour for JamVM, the reason “why?” are that CACAO depends on the HPI API that have been removed from the OpenJDK 7 code base. This means that CACAO currently only work in combination with the “classic” OpenJDK 6. The second black cloud for CACAO JVM on ARM was that all major ARM Linux distributions started to move from “armel” towards the new “armhf” ABI something CACAO do not support. JamVM here provided the ARM Linux distributions and users with a stable and future proof alternative.

If we for a moment forget about the future and focus on today CACAO are in great shape when built from CACAO hg HEAD.

  • CACAO are FAST,
  • CACAO are stable, thanks to Stefan Ring who have been diligent on fixing bugs found in the CACAO JIT codegen.
  • CACAO are fresh, the current CACAO hg HEAD contains the rewritten, “still unreleased” C++ version of CACAO its a totally different JVM compared to the last C based release of CACAO 0.99.4.

If you want to experience the CACAO JVM in its finest the do run the latest development version of CACAO in combination with OpenJDK 6, built using the current IcedTea6 head. Run it on ARM “armel”, PPC or MIPS and experience a fast responsive JVM burning brighter than ever before!

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.

« Newer PostsOlder Posts »

Powered by WordPress