Java

[forumisto]

Are a Java version for RaspberryPi?

Thanks

[antiloquax]

If you are using Arch, try:

Code: Select all

pacman -S jdk7-openjdk

It's in the repo.
Arch Arm Packages

[precious_pony]

Is that a version with JIT compilation?

[mredeker]

The openjdk does not include JIT.
Only the Oracle EJRE does include JIT for arm.

[dacha]

Is that a version with JIT compilation?

On the Debian image, you can install the openjdk-6-jdk package, which will automatically pull in the icedtea-6-jre-cacao package. Then:

• "java ..." runs Zero, which is an interpreter in the official OpenJDK JVM written by Gary Benson (http://gbenson.net/). It's portable, but very slow and can't JIT.
  "java -cacao ..." runs Cacao, an alternative JVM which JITs.

For example compare the output of "java -version" and "java -cacao -version".

I find Cacao to be 50 times faster than Zero in one small benchmark. The stability, reliability, compatibility, memory usage etc. remain to be seen.

Gary Benson also had a project called Shark which uses LLVM to JIT on various architectures. But LLVM doesn't support ARM when last I checked, so we can't use that yet.

There's also JamVM to consider, but I don't know how good it is. Debian doesn't seem to have a package for it either.

[xranby]

Is that a version with JIT compilation?

"java ..." runs Zero, which is an interpreter in the official OpenJDK JVM written by Gary Benson (http://gbenson.net/). It's portable, but very slow and can't JIT.

There exist two variants of Zero, the generic C++ interpreter variant built from OpenJDK directly and a mixed mode variant from IcedTea that is based on the OpenJDK variant with a ARM assembler interpreter and a Thumb2 JIT addon. http://www.raspberrypi.org/phpBB3/viewt ... 72#p103672

There's also JamVM to consider, but I don't know how good it is. Debian doesn't seem to have a package for it either.

Debian have packaged JamVM in Wheezy, its found in the icedtea6-jre-jamvm package.
JamVM have some unique strenghts found in quick jvm statup time and low memory overhead.

Overview of various JVM variants on the Pi running the SciMark2 benchmark for numeric floatingpoint computations:

The OpenJDK tests in this overveiw was run using:

Code: Select all

wget http://math.nist.gov/scimark2/scimark2lib.jar
java -cp scimark2lib.jar jnt.scimark2.commandline

The statically ahead of time compiled GCJ+classpath tests was run using:

Code: Select all

wget http://math.nist.gov/scimark2/scimark2lib.jar
gcj -O2 -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=softfp -o scimark2 --main=jnt.scimark2.commandline scimark2lib.jar
./scimark2

For this floatingpoint intense benchmark two ways of running java code on the Pi stands out:
- The current fastest way to run java code on the Pi is to use ahead of time compiation using GCJ.
- The current fastest JIT to use on the Pi is to use CACAO from IcedTea6 1.11.x on Debian Wheezy.

[ctday]

I'm just starting to learn anything about the ARM architecture, so this may well be a stupid question - Do any of the JVM options available or pending make use of the Jazelle direct-byte-code-execution instructions? Thanks.

[xranby]

I'm just starting to learn anything about the ARM architecture, so this may well be a stupid question - Do any of the JVM options available or pending make use of the Jazelle direct-byte-code-execution instructions? Thanks.

It is a good question, There exist two variants of Jazelle:

Jazelle v1 also called Direct Bytecode eXecution, DBX, this is the variant found in the Pi, unfortunally no complete documentation exist how to implement and make use of this runtime mode in software so i doubt any open source JVM will ever be able to use this runtime mode. DBX was designed to speed up startup time of JavaME to let the JVM run bytecodes while the JIT was initializing. To my knowledge you need to be a JTEK licensee to be allowed to use Jazelle DBX.
In reality i think JamVM+OpenJDK will start equally fast or faster than any JTEK/DBX enabled JVM.

Jazelle v2 also called Run-time Compilation Target, RTC, this is basically the Thumb2 instructionset. The OpenJDK+Zero Mixed Mode JVM with a Thumb2 JIT uses it. Jazelle RTC is designed to be a good target for any JIT computer language so its not even Java specific. Jazelle v2 exist in all ARMv7 cores and later.

[Howard]

My software (a model railway control system written in Java) needs RXTX or similar (to connect to the interfacing hardware) and hsqldb (or some other JDBC SQL database).

I have started with Debian and OpenJDK-6

Zero is so slow its totally unusable (but it works, I think).
Cacao won't load the rxtxSerial.so (System.getProperty ("java.library.path") also returns null) and neither hsqldb1.8 or 2.0 works (different but disastrous exceptions).

OpenJDK-7 isn't available on Debian

sun-java isn't available on our architecture

A previous message said OpenJDK-7 is available on Arch but the discussion on Arch sounds as if its too buggy to use just yet.

Do I have any other choices?

[xranby]

My software (a model railway control system written in Java) needs RXTX or similar (to connect to the interfacing hardware) and hsqldb (or some other JDBC SQL database).

Are you using JMRI?

I have started with Debian and OpenJDK-6
Zero is so slow its totally unusable (but it works, I think).

I believe you are trying to run a heavy swing application on the Pi to display the railway network.
The slowness you see is most likely related to the fact that all java2d in openjdk have no choice but fallback to pure software rendering of all swing/awt gui, thus the slow operation is caused by the java2d backend and not the JVM itself.
I would suggest you to try some of the alternative java2d backends like try using the xrender backend across a remote ssh -X session. To activate xrender pass -Dsun.java2d.xrender=True to java when launching your application, it might help a little to speed up java2d.

Cacao won't load the rxtxSerial.so (System.getProperty ("java.library.path") also returns null) and neither hsqldb1.8 or 2.0 works (different but disastrous exceptions).
OpenJDK-7 isn't available on Debian

I think you are currently using Debian "squeeze".
If you instead try the new Debian "wheezy" beta, then this version contains a major updated, rewritten from c to c++ cacao 1.0.x version for use in combination with openjdk-6. openjdk-7 is available as well in Wheezy.

sun-java isn't available on our architecture

Oracle currently offer JavaSE embedded for ARMv6/7 Linux - Headless - this should work on the Raspberry Pi, It is a headless build without AWT/Swing so it should work unless you require an GUI.
http://www.oracle.com/technetwork/java/ ... index.html

Do I have any other choices?

You can try jamvm + openjdk that is also found in debian wheezy.

[Howard]

Are you using JMRI?

No. Its my own software that I started around 1999. It has grown quite a bit since then.

I believe you are trying to run a heavy swing application on the Pi to display the railway network.

It is certainly a swing app, I don't consider it 'heavy' as the GUI thread uses only one quarter of the CPU that the whole app uses.

I think you are currently using Debian "squeeze".
If you instead try the new Debian "wheezy" beta, then this version contains a major updated, rewritten from c to c++ cacao 1.0.x version for use in combination with openjdk-6. openjdk-7 is available as well in Wheezy.

Correct. I have now downloaded Wheezy and openjdk-7 and its lots faster.
Running plain java is a little faster than -cacao was on squeeze, and it seems to work (a few problems to sort out yet though).
java -cacao doesn't even get started (I get jmm_GetBoolAttribute: Unknown attribute 24) so thats something to look at later.

Oracle currently offer JavaSE embedded for ARMv6/7 Linux - Headless - this should work on the Raspberry Pi, It is a headless build without AWT/Swing so it should work unless you require an GUI.

But I need a GUI to be able to see whats going on. But yes I knew it was available, just not applicable

You can try jamvm + openjdk that is also found in debian wheezy.

I don't particularly need fast startup or low memory usage - I still have half the memory free when its running.

Many thanks for your help - it has certainly moved me forward.

[Howard]

I was slightly hasty in my previous analysis.

Java on Squeeze was indeed a disaster for me.

On Wheezy most combinations (6 or 7, zero, cacao, jamvm) loads libraries and starts reasonably quickly so thats better than Squeeze but after a little the XAWT thread consumes all the CPU even if I just have a single, rather empty window open.

Catching stack traces every few seconds and saving them (in memory) it seems that the thread (called AWT-XAWT) is sun.awt.X11.XToolkit and it spends more time converting events to strings for disabled logging than it does dispatching events.

So I deduce we have a debug version of XToolkit in arm-openJDK. I guess there is nothing we can do about that until the openJDK team decide it works properly.

[Howard]

P.S. I also tried the xrender=true suggestion.

JVM crash & bug file. Not so good

[xranby]

On Wheezy most combinations (6 or 7, zero, cacao, jamvm) loads libraries and starts reasonably quickly so thats better than Squeeze but after a little the XAWT thread consumes all the CPU even if I just have a single, rather empty window open.

Catching stack traces every few seconds and saving them (in memory) it seems that the thread (called AWT-XAWT) is sun.awt.X11.XToolkit and it spends more time converting events to strings for disabled logging than it does dispatching events.

So I deduce we have a debug version of XToolkit in arm-openJDK. I guess there is nothing we can do about that until the openJDK team decide it works properly.

Oracles Java2D team is aware of this bug, it is a generic bug and it triggers sporadically on many different systems and configurations:
http://bugs.sun.com/bugdatabase/view_bu ... id=7105941
Unfortunately no known fix is available yet.

[xranby]

P.S. I also tried the xrender=true suggestion.

JVM crash & bug file. Not so good

Hmm.. looks like this bug trigger when trying to use the java2d xrender backend in combination with the framebuffer xorg driver on the pi. you may send this crash log, and possibly a reproducer, to the icedtea bugzilla and we can try figure out if the crash happened inside the xrender backend itself or inside the framebuffer xorg server.

[xranby]

On Wheezy most combinations (6 or 7, zero, cacao, jamvm) loads libraries and starts reasonably quickly so thats better than Squeeze but after a little the XAWT thread consumes all the CPU even if I just have a single, rather empty window open.

Catching stack traces every few seconds and saving them (in memory) it seems that the thread (called AWT-XAWT) is sun.awt.X11.XToolkit and it spends more time converting events to strings for disabled logging than it does dispatching events.

So I deduce we have a debug version of XToolkit in arm-openJDK. I guess there is nothing we can do about that until the openJDK team decide it works properly.

Oracles Java2D team is aware of this bug, it is a generic bug and it triggers sporadically on many different systems and configurations:
http://bugs.sun.com/bugdatabase/view_bu ... id=7105941
Unfortunately no known fix is available yet.

Please double check your code to verify that all awt and swing code runs on the event dispatch thread. You do this by for example changing

Code: Select all

public static void main(String[] args) {
        createAndShowGUI();
}

to

Code: Select all

public static void main(String[] args) {
    SwingUtilities.invokeLater(new Runnable() {
        public void run() {
            createAndShowGUI();
        }
    });
}

By using the SwingUtilities.invokeLater you guarantee that this code is properly scheduled to run on the EDT thread. Remember that Swing is not thread safe by design and you as the programmer must guarantee that all swing calls happens from this Event Dispatch Thread.
http://docs.oracle.com/javase/tutorial/ ... index.html

[Howard]

Please double check your code to verify that all awt and swing code runs on the event dispatch thread.

Now thats going to be a challenge. My app uses several threads (one to interpret a script, two per port handle serial port comms, one to compile another script, one to load images and more). It is entirely possible for some swing updates to have crept in considering the vast number of places that updates might occur.

I had considered that working correctly on Mac and Windows, and previously working on Solaris and Linux meant that the code was correct. Silly me.

But thanks very much for that insight. I'll have to find some time to check the whole App now.

[Howard]

Please double check your code to verify that all awt and swing code runs on the event dispatch thread.

Done. Not as bad as I had expected! Now all GUI calls are in the event thread, including component creation which used to be allowed anywhere.
I have used CheckThreadViolationRepaintManager to catch the bits I missed and now the only report is for JTextArea.append which is documented as thread safe.

Trouble is it hasn't improved the situation at all. Start the App and it does all its startup (at a good speed) and then the CPU usage goes down. Move the mouse pointer just a tad and CPU goes back to 100% and the whole system grinds so slow its like watching paint dry. No clicking, just the slightest mouse movement is all it takes.

[dinfangion]

For java on Arch Linux:
uname -a
Linux alarmpi 3.1.9-22-ARCH+ #1 PREEMPT Sun Jun 17 13:54:30 UTC 2012 armv6l GNU/Linux

pacman -Q openjdk6
openjdk6 6.b22_1.10-1

compiler:
/usr/bin/javac

java -version
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10) (ArchLinux-6.b22_1.10-1-arm)
OpenJDK Zero VM (build 19.0-b09, interpreted mode)

from the Oracle website
http://www.oracle.com/technetwork/java/ ... index.html
Java SE Embedded 6
ejre-1_6_0_32-fcs-b05-linux-arm-vfp-eabi-headless-05_apr_2012.tar.gz

/opt/ejre1.6.0_32/bin/java -version
java version "1.6.0_32"
Java(TM) 2 Runtime Environment, Standard Edition for Embedded (build 1.6.0_32-b05, headless)
Java HotSpot(TM) Embedded Client VM (build 20.7-b02, mixed mode)

symbolic link for missing libffi.so.5
ln -s /usr/lib/libffi.so.6 /usr/lib/libffi.so.5

http://docs.oracle.com/javase/tutorial/ ... /unix.html
[root@alarmpi opt]# java HelloWorldApp
Hello World!

[Howard]

Please double check your code to verify that all awt and swing code runs on the event dispatch thread.

OK, I've got my software running. I don't think the swing threading was an issue, but I am still 'fixing' issues as they arise.

The killer turned out to be creating a JDBC Statement using HSQLDB (which was the database that I'd found worked best for me). Just commenting out:

Code: Select all

stmt = con.createStatement ();

Allowed the App to startup without XAWT going wild.

Changing to the newer H2 database (written by the same person as HSQL) or to Derby (rather bigger and slower) it worked fine.

[xranby]

Please double check your code to verify that all awt and swing code runs on the event dispatch thread.

OK, I've got my software running. I don't think the swing threading was an issue, but I am still 'fixing' issues as they arise.

The killer turned out to be creating a JDBC Statement using HSQLDB (which was the database that I'd found worked best for me). Just commenting out:

Code: Select all

stmt = con.createStatement ();

Allowed the App to startup without XAWT going wild.

Changing to the newer H2 database (written by the same person as HSQL) or to Derby (rather bigger and slower) it worked fine.

Happy to hear that your project is now running.
Please post a picture or write blog-post of your Pi Java controlled model train network this is so cool!

[Howard]

Happy to hear that your project is now running.
Please post a picture or write blog-post of your Pi Java controlled model train network this is so cool!

If you go to http://groups.yahoo.com/group/mergtcc/ you can see a screen capture of my main track diagram window. But strictly my Tcc program does not define anything of what it does - it merely interprets a TCL (Train Control Language) script, handles serial port comms for several protocols (to different interface hardware) and gives the script control of various GUIs. My personal script does everything, including driving the trains, but of course that needs suitable external hardware. Some other people use it for route setting, and some for despatcher duty.

The PI project I was working towards was for despatcher duty: keep track of train location and timetable to allow the human despatcher to respond to shunting and movement requests from all over the single track layout. The execution engine, the script, external SQL database and GUIs are all working well. Noticeably slower than on a Mac or PC but still usable.

Unfortunately I found that turning on the serial port (using RXTX) uses a *LOT* of CPU on the Pi and the whole package then ran rather too sluggish, even at 800MHz. I must try again now we have 1GHz available.

Making Tcc run on a Pi has been an interesting project because it brings back processing efficiency into ones consciousness. I have always tried to design things to run efficiently but some reworking recently (pre-Pi) meant that the GUI work for the main CTC windows (like the track diagram) was reduced to 40% of what it was previously. I have made some more modest gains while working on the PI.

What I have noticed is that just moving the mouse takes a *LOT* of CPU redrawing the pointer. Moving the mouse (only lxterminal and task manager running) takes the CPU from an idle 3% to 60-70%. This is with firmware downloaded a few days ago. Probably a bit of an issue for most mouse-using applications. I guess the USB driver that collects mouse input needs to regulate events into the system to no more than 10 a second. Whatever the issue is here I am confident that someone will come up with a fix before too long as it must affect most Pi-users.