Dismal Java (OpenJDK) performance on F17

[gregjo]

I've installed MySQL and Tomcat6 on my R-PI. I put a copy of a test database I have, and then a full web app on it. Why? Because I can! I didn't expect it to perform well, but had to do it anyway....for fun. Because, face it, we all want to try and run our production software on a cellphone-class CPU, right?

First I did this exercise using the Debian distro. I'm a long-time Red Hat user, but I learned a fair amount of Debian as I went.

The "server" response was sluggish, but it worked. Serving up a JSP page that hits the database takes about 5 seconds. A page compile (in Java) takes quite a bit longer....about 38 seconds for a rather simple page. (My most complicated page takes over 50 seconds to compile).

Here are the relevant components I installed for Debian:

mysql-server 5.1.49-3
tomcat6 6.0.35-1+squeeze2

# java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze1)
OpenJDK Zero VM (build 14.0-b16, mixed mode)

Then I decided to try one of the experimental builds of F17 ("console" version ) put together by effbiai. (See this thread:
http://www.raspberrypi.org/phpBB3/viewt ... =51&t=5466

The performance to page compile a JSP page under Fedora is very poor compared to the Debian distro.
Under Debian, a page hit that accesses the database took 5 seconds. The same page under Fedora took 9 seconds. Although nearly double the time, it didn't feel too bad. But when it came to page compiling, it was a much different story. The simple page that took 38 seconds under Debian to compile now takes 1 min 17 seconds under Fedora. The more complex page that took 50 seconds in Debian took 1 min 52 seconds under Fedora.

These are the relevant packages I installed under Fedora:

mysql-5.5.23-1.fc17.armv5tel
tomcat6-6.0.32-20.fc17.noarch

# java -version
java version "1.7.0_b147-icedtea"
OpenJDK Runtime Environment (fedora-2.1.fc17.6-arm)
OpenJDK Zero VM (build 22.0-b10, interpreted mode)


Now....this wasn't a very well planned out experiment. I just grabbed whatever version of Java came from the package management system when I installed Tomcat6. I vaguely recall another thread saying there were significant differences between different JVMs on ARM. I'll go look that thread up. But I just wanted to throw my experiment out here for rumination. I may be calling out the distro as the problem, when it might very well be the JVM. But it was the JVM that got installed by default.

[dacha]

"Zero VM" is a pure interpreter, so it's very slow. Try using the Cacao virtual machine instead which JITs. On Debian you can use "java -cacao ..." in place of "java ...". For example compare "java -version" to "java -cacao -version".

[xranby]

The main reason why you see a magnitude difference in the Debian vs Fedora results really boils down to that there exist two variants of Zero.

In Fedora you have installed OpenJDK Zero VM (build 22.0-b10, interpreted mode)
This is using the C++ interpreter only.

In Debian you have installed OpenJDK Zero VM (build 14.0-b16, mixed mode)
The "mixed mode" version contains two addons, designed by Edward Nevill, on top of the generic Zero C++ interpreter, a rewritten interpreter main loop in ARM assembly this speeds up the jvm about a factor x3 this do benefit the Pi.
The "mixed mode" also include a Thumb2 JIT that improves speed for ARMv7 cores and later, the Pi could benefit from this JIT if it got rewritten from Thumb2 to target generic ARM or Thumb1 assembly.

If you want the longer background why these ARM assembler addons on top of Zero got created then read the gossip from the local pubs in Cambridge:
How do you make Java fast? A: Go down the pub
How do you make Java fast? A: Go down the pub, part 2


For distribution packagers:
Only some of the upstream IcedTea releases contains the Zero "mixed mode" variant with the assembler interpreter and Thumb2 jit addons. The current supported IcedTea versions that include the Zero mixed mode are:
IcedTea6-1.11.x and IcedTea7-2.1.1

[gregjo]

The interpreted mode version of Java installed under Fedora does not support the cacao option as suggested by dacha.

So.....how do I go about getting the mixed mode version, as discussed by xranby? I feel like I'm beating my head against the wall. Using the links provided, I am attempting to build IcedTea7-2.1.1. However, this seems to be a very difficult proposition on such humble hardware. I was able install all of the components necessary to compile, but the compile steps use far too much memory. I was going to say that I can see things in the build script as they fly by....but they just crawl by. I have hours to ponder the configurations, as not much happens for a very long time.

Code: Select all

/opt/icedtea-2.1.1/bootstrap/jdk1.6.0/bin/javac -J-XX:ThreadStackSize=768 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-client -J-Xmx512m -J-Xms512m....

Specifying a 512m heap certainly caused my eyebrows to raise. I have implemented a swap partition so it can at least have a chance to make it through the compile steps.....but swapping like crazy to an SD card is rather insane. The build process chugs along for about a day, and then the machine finally hangs.

Is there somewhere I can optain a pre-packaged "interpreted mode" Java for Fedora on ARM?

[shawnanastasio]

I recommend cross-compiling using a program named "Scratchbox". I am fairly new to java, and I was unable to compile OpenJDK in Scratchbox (I am not sure if i read it right, but i think you need java to compile java???) If someone could correct me, and tell me how to compile OpenJDK (mixed mode) I would be glad to do it and upload it. I have access to a oct-core (8 core) machine with 48GB of ram, so I have the resources to compile it, just lack the knowledge.

--Shawn

[chrisg]

I haven't tried cross-compiling OpenJDK (I read somewhere that it's not straightforward) but I have had some success in the past compiling it in a qemu ARM emulator environment on a PC.

[edh]

Yes, you should definitely use cacao on armel archs like the Pi, not Zero. If you have issues switch back to Zero, figure out the problem - then file a bug with the Cacao team. They will respond. Cacao's performance is quite good on ARM.

[gregjo]

>Yes, you should definitely use cacao on armel archs like the Pi, not Zero.

All well and good....but where to find Cacao on Fedora? I can't find an ARM version for F17. I'm attempting to build it from source, but not having much luck yet.

[rastapi]

Hi, perhaps my issue is not that related to the original post, but I too am experiencing dismal java performance, running subsonic media streamer on raspbian, and there isn't many forums to discuss such issues on.

I have had subsonic working perfectly. I'm running subsonic-4.7.beta3.deb which seems to be the most stable, have installed openjdk-6-jre as subsonic suggest, and have managed to successfully stream for a couple of weeks without any problems at all really, both locally and externally.

There has been two occasions though where java cpu usage has reached staggering heights. I'm talking 99% at moments! and this leaves raspberry pi completely unusable. So today I am unable to access my subsonic page locally or externally and the pi is running at 98% because subsonic java is seemingly doing something even though it is freshly installed.

Would any one have any ideas as how to remedy this? I've thought about changing the cpu memory split but it doesn't seem to be a memory issue; I've reinstalled subsonic (which seemed to work last time), but this has failed to make the situation better this time. Others on the subsonic forum have mentioned something about using oracle java instead, but I wouldn't really know which to get.

Of course this may just be a bug with the subsonic beta and may get fixed.

Any ideas and help is really appreciated! Thanks.

[xranby]

Hi, perhaps my issue is not that related to the original post, but I too am experiencing dismal java performance, running subsonic media streamer on raspbian, and there isn't many forums to discuss such issues on.

I have had subsonic working perfectly. I'm running subsonic-4.7.beta3.deb which seems to be the most stable, have installed openjdk-6-jre as subsonic suggest, and have managed to successfully stream for a couple of weeks without any problems at all really, both locally and externally.

There has been two occasions though where java cpu usage has reached staggering heights. I'm talking 99% at moments! and this leaves raspberry pi completely unusable. So today I am unable to access my subsonic page locally or externally and the pi is running at 98% because subsonic java is seemingly doing something even though it is freshly installed.

Would any one have any ideas as how to remedy this? I've thought about changing the cpu memory split but it doesn't seem to be a memory issue; I've reinstalled subsonic (which seemed to work last time), but this has failed to make the situation better this time. Others on the subsonic forum have mentioned something about using oracle java instead, but I wouldn't really know which to get.

Of course this may just be a bug with the subsonic beta and may get fixed.

Any ideas and help is really appreciated! Thanks.

Try the icedtea-7-jre-jamvm package
a) start java with java -jamvm
b) edit /etc/java-7-openjdk/jvm-armhf.cfg and place -jamvm KNOWN at the top of the list.
It should improve performance.

Please open a new forum thread if the problem persist.

[xranby]

>Yes, you should definitely use cacao on armel archs like the Pi, not Zero.

All well and good....but where to find Cacao on Fedora? I can't find an ARM version for F17. I'm attempting to build it from source, but not having much luck yet.

Can you try run the F18 built OpenJDK packages?
Fedora currently build IcedTea 7 2.1.2 , most likely they would be happy if you file a patch against their git to enable Fedora jamvm and cacao builds. The IcedTea build-system can build JamVm as one additional JVM when passing --with-additional-vms=jamvm to configure.
Also IcedTea 2.3.2 is out, it might be an idea to persuade fedora build this new release instead.
http://pkgs.fedoraproject.org/cgit/java ... k.git/log/

[rastapi]

Hey, thanks for the response.

I have been able to remedy my performance issue, without installing any different or separate packages.

My 99% cpu usage was due to the leap second bug the linux ntp server experiences. By stopping the raspi ntp server the issue is resolved.

Cheers.