zafena development

February 8, 2013

This post is about an solution to an old chest nut that still plague ARM Java users on both servers, desktop and mobile. The problem it the impossibility to query the JVM system properties to find out the ABI armel/armhf in use, on ARM systems and possible other ARCH ABI variants as well such as x32, because no information about the ABI is exposed using said system properties. It is mandatory for developers to know the ABI in use at runtime in order to load matching JNI libraries.

About one year ago in 2012 the question got raised inside the #OpenJDK IRC channel but nothing really happened.
Later in 2012 the same question got raised inside the Raspberry Pi community during the move to the new Rasbian armhf system, but nothing really happened except adding more or less creative workarounds to all ARM Java applications and libraries.

The Raspberry Pi community eventually added a Java specific forum and now Oracle engaged in the community and asked for questions: So the question got raised again.
In the end of 2012 Oracle launched their first armhf JVM for the Raspberry Pi but the os.arch namespace was still not fixed, after reporting a workaround for the new JDK 8 EA Oracle took notice.
In the beginning of Jan 2013 Oracle Bob Vandette started an discussion on how to introduce an extended properties namespace that would cover the ABI differences to let applications discover the ABI at runtime.

During the FOSDEM 2013 JogAmp re-raised the question in front of the Oracle audience at 19m23s into the JogAmp talk and the response was "We just discussed that last week". So our reply is "So we can not wait for that". This issue is still causing hairpulling for ARM Java server/desktop/mobile deployments where for example the JVM tries to load armel JNI on the new armhf ARM Linux systems because the system properties set by the new armhf JVM is identical to an armel JVM, loading a library of the wrong ABI do not work.

Q: So what can we do about it?
A: Include an #freejava ELF header parser of course!

#JogAmp #gluegen now implements and use the following ELF header parser:;a=commit;h=371e1dbff6f5f255ab27ed0ab32368abb06eed82 … in order to find out the ABI at runtime without relying on if proper #JVM os.arch & ABI properties are set or not.

Kudos to Sven Gothel for implementing the new ELF header parser using the Gluegen StructAccessor.
Kudos to Andrew Haley, aph, who hatched the idea inside the #OpenJDK IRC channel to scan /proc/self/exe using an elf header parser from within the Java process itself and look for the Tag_ABI_VFP_args ELF header flag, this is what the implemented gluegen solution is based on.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress