Older blog entries for rlougher (starting at number 14)

Filesystem Collaboration

My twin brother is the author of SquashFS. A very influential Linux filesystem used on practically all Live CDs. He reads the Linux Magazine interview with Valerie Aurora who says:

hoping that if the existing Linux file systems developers could just talk to each other, we could come up with a way to improve funding for Linux file systems development. I don’t know that it helped, but if it did, I consider this to be my most important contribution to Linux file systems.

So decides to link up via LinkedIn, and gets refused...

Syndicated 2009-07-17 23:41:00 (Updated 2009-07-17 23:54:49) from Robert Lougher

12 May 2009 (updated 12 May 2009 at 15:11 UTC) »

Netifera uses JamVM as remote probe

Netifera is a very interesting 100% Java-based Open Source network security platform. The next version will include a probe, which is a "deployable software agent that makes it possible to run all netifera platform tools remotely".

The probe uses JamVM and a cut-down version of GNU Classpath. This is downloaded onto the remote site to run the netifera tools. My thanks to Claudio Castiglia (of Netifera) for sending me the following link to a webcast showing the probe in action:

http://netifera.com/video/netifera_java_virtual_machine_as_shellcode


JamVM and GNU Classpath are mentioned starting 14:54 into the webcast in the discussion of the probe architecture.

Syndicated 2009-05-12 01:04:00 (Updated 2009-05-12 14:11:42) from Robert Lougher

JamVM on Beagle Board

I've been intending to get a Beagle Board for quite a while now, to replace a Neo1973 as the development platform for JamVM on ARM. The Neo has an ARM920T core, and I've been particularly wanting to test JamVMs code-copying JIT on a more modern implementation (the Beagle Board has a Cortex A8). But I've been waiting for the Rev C board, as this has working EHCI USB host, and 256MB RAM (previous revisions had 128MB). The board arrived 2 weeks ago, but I haven't had much time to set it up until now...

So far, the results are quite encouraging. SciMark 2.0 shows a 55% speed improvement:



While jBYTEmark shows an 82% improvement on Integer tests:



The option -Xcodestats prints out the size of the JIT code-cache when the VM exits. This shows 77K was used after running SciMark 2.0, and 178K after jBYTEmark. This is using the code-profiling introduced in JamVM 1.5.2.

Syndicated 2009-05-11 21:55:00 (Updated 2009-05-12 00:53:32) from Robert Lougher

17 Mar 2009 (updated 17 Mar 2009 at 11:17 UTC) »

JRuby 1.2.0RC2

I read with interest Jeroen's recent post on his blog about his experiences running JRuby 1.2.0RC2 on IKVM. I know I don't run enough "real-world" tests on JamVM, so I finally got around to trying to run it on JamVM over the weekend. Then wished I hadn't. I secretly hoped it would "just work", but it almost immediately segv-ed. This was the first of 5 problems.

The segv was relatively easy to find and fix. A regression introduced in JamVM 1.5.1, when I added unloader objects to unload JNI libraries after the classloader which loaded them is garbage-collected. This was itself a fix for library unloading, which used to be done within GC, but broke if the JNI_OnUnload function called back into Java.

Basically, I didn't take into account libraries which have a JNI_OnUnload function being loaded by the boot classloader (the NULL loader). This is pointless, as the boot classloader is never collected, and therefore no library loaded by it can be unloaded. However, the fix was simple - just ignore them.

The next problem was with MemoryManagerMXBean. I spent some time implementing native support for ThreadMXBean in JamVM 1.4.4 as part of the thread re-work, but never got round to implementing the full set, as nothing much seemed to use them. For now, a simple implementation which just returns "no memory managers" appears to be sufficient.

After that there was a problem with annotations, where an AnnotationTypeMismatchException was being thrown. This took some time to track down because I had to remember how annotations worked! It ended up being a mismatch between an annotation array value and the method return type. When parsing the annotation, the array values can be any one of a number of types, so in JamVM an Object array is created (when the array is created, the elements haven't yet been parsed so the type isn't known). But the method return value is the specific type, in this case String[]. Luckily, a similar problem has been found with the implementation in gcj, so I was able to adapt the fix into JamVMs version of sun.reflect.annotation.AnnotationInvocationHandler.

Problem number 4 was with VMClassLoader.getPackage(). The default GNU Classpath implementation relies on a META-INF/INDEX.LIST file existing in the first Jar in the bootclasspath. JRuby uses Constantine, which uses the package name to load an appropriate constant class. As the Constantine Jar is added to the bootclasspath, even if the INDEX.LIST existed, it wouldn't have any package information for it. A quick and dirty implementation of VMClassLoader.getBootPackages() which doesn't need INDEX.LIST fixed this.

Finally, there was a problem with Class.getSimpleName(). The simple name is appended to the package name to locate the constant class. However, the GNU Classpath implementation of getSimpleName (which delegates to VMClass) is broken. Again, I took the fix from gcj.

After all this, jRuby runs!

rob@dougal:~$ jruby hello.rb
Hello World!

The next thing to try was jirb (interactive shell). For some reason, the default prompt doesn't work (nothing is shown, it may be related to sun.misc.Signal, as jirb complains about an unsupported trap). However, the simple prompt does.
rob@dougal:~$ jirb --prompt simple
trap not supported or not allowed by this VM
>> include_class java.lang.System
include_class java.lang.System
=> Java::JavaLang::System
>> System.getProperty("java.vm.name")
System.getProperty("java.vm.name")
=> "JamVM"
>> System.getProperty("java.vendor")
System.getProperty("java.vendor")
=> "GNU Classpath"
>> quit
quit

Syndicated 2009-03-17 01:18:00 (Updated 2009-03-17 10:42:55) from Robert Lougher

Benchmarks

A couple of people after my talk at FOSDEM asked me where the benchmarks were. I didn't have any partly because I didn't think there was time in the talk, partly because I didn't know what to benchmark against, and mostly because I hadn't had time to do any.

So, I've finally done some. I've benchmarked against the JDK template interpreter, because of the interest due to the recent work of Shark and Zero. The benchmarks are from SPECjvm2008. Not all of these run with GNU Classpath, and from the rest, I've selected benchmarks which should hopefully not be influenced by the different class libraries.
Note, these benchmarks are not compliant, and I am in no way publishing these results. For the record, the benchmarks were ran on an Athlon 64x2 3800+.

Syndicated 2009-03-02 00:41:00 (Updated 2009-03-02 02:47:54) from Robert Lougher

BUG Labs JVM saga end game

I've been following Bug Labs choice of JVM quite closely. After a series of comparisons between JamVM, CacaoVM and PhoneME they adopted PhoneME (initial test here and the follow-up). I blogged on the results of the first test, which were favourable to JamVM. However, for the second test, they sorted out the problems with running PhoneME's JIT, and the positions of JamVM and PhoneME reversed.

This was disheartening, but the results spoke for themselves. However, one odd fact is that the second test did not give any details of start-up time. JamVM clearly won this in the first test, and it's unlikely enabling PhoneME's JIT would have changed this.

So, I read with great interest the recent blog entry where they've got CacaoVM/GNU Classpath running on the BUG. It appears they will still ship with PhoneME, but CacaoVM/GNU Classpath will be an option for customers who require the Classpath exception.

So what? Well, I'd like an explanation why they seem so reluctant to use JamVM. From their own tests, JamVM came out on top for start-up, and came second in performance to PhoneME with JIT.

Perhaps they've finally cracked the performance problems with CacaoVM. But JamVM is not configured for top performance on ARM either (by default, the inlining interpreter is disabled on ARM).

Of course, there are many other advantages to JamVM on embedded systems besides start-up time. It has its own, compacting garbage-collector with full support for soft, weak and phantom references in addition to class unloading. CacaoVM relies on Boehm GC, exhibiting memory fragmentation issues, and it has no support for soft/weak/phantom references or class-unloading.

Things like this makes me very disheartened. As I've said before, it makes me wonder why I continue to work on JamVM at all. However, giving up will be a case of "cutting my nose off to spite my face".

If they've hit any problems with JamVM I'll be quite happy to work with them to fix them, but I've received no feedback or requests. Unfortunately, I have been unable to leave any comments on the blog entry itself. On enquiring with the webmaster, it appears that this is new software which is at an early stage. However, they've put this functionality at the top of their TODO list, and I can expect it in a day or two (thanks Brian).

To finish on a positive note, I've done quite a lot of work on JamVM over the last few months, including memory footprint and performance improvements over JamVM 1.5.1. Hopefully I'll make a new release before Christmas.

Syndicated 2008-12-09 20:13:00 (Updated 2008-12-09 22:12:51) from Robert Lougher

JamVM/GNU Classpath/iPhone roundup

It's a year since JamVM was ported to the iPhone/iPod Touch. A quick browse on Google shows up a couple of interesting things:

But my favourite is a benchmark shootout between Java (JamVM), Ruby and Python. Just the one benchmark, but JamVM is almost 6 times faster than Python (5.86), and over 15 times faster than Ruby (15.02). It's in Japanese, but the bar chart at the end is clear.

Syndicated 2008-11-17 17:04:00 (Updated 2008-11-17 19:02:10) from Robert Lougher

Lend me an ear while I call you a fool*

As the developer and maintainer of JamVM I get a regular stream of emails about licencing issues (2 so far this week). But this one left me speechless:

What is your intent for users of the JamVM code? Is it just the core of the VM that you have licensed using GPLv2, and so any changes to that core code or code linked with it must be provided as opensource? Since the class libraries come from Gnu Classpath, they are covered under the so-called 'classpath exception', and don't infect code that link with it, correct? Thus, is it allowed for a company to make a product using an unmodified JamVM as a standalone program that executes proprietary and unpublished Java code, without running afoul of GPLv2?
While the question is clear, the use of the pejorative terms "infect" and "afoul" towards GPLed code immediately gets my back up. My instinct is simply to ignore it, but is there any more appropriate response?

* With apologies to Jethro Tull.

Syndicated 2008-11-16 20:54:00 (Updated 2008-11-16 21:59:11) from Robert Lougher

31 Jul 2008 (updated 1 Aug 2008 at 00:06 UTC) »

Embedded JVM comparison

Buglabs have done a comparison of open-source JVMs on their embedded ARM platform (the BUG, based on an ARM1136JF-S core). The tested VMs were PhoneME advanced, Cacao and JamVM. The results are very interesting :

http://bugblogger.com/java-vms-compared-160/

JamVM comes out the fastest, followed by PhoneME and then Cacao. On startup time, JamVM also comes out top (3 ms), followed by Cacao (12 ms) and PhoneME (16 ms).

The caveat is that PhoneME's JIT is not being used because of kernel issues (and presumably, its startup time would increase even further). The real mystery, however, is the poor performance of Cacao. A good result for JamVM is meaningless if the test isn't fair.

The benchmarks used in the test are dominated by floating point. Looking at the Technical Reference Manual for the ARM core shows that it has a Vector Floating-Point (VFP) coprocessor. As long as the toolchain is correctly setup this should be supported by JamVM. The question is whether Cacao's JIT correctly produces floating-point instructions or always uses emulation.

Another possibility is cache behaviour. The performance improvement of JIT code being offset by increased I-cache misses (an interpreter should fit entirely within the cache). JamVM's inlining interpreter is disabled on ARM, the direct-threaded interpreter being used by default. This is because inlining/super-instructions showed no performance improvement despite 200-300% improvement being seen on AMD64 (at least on an ARM920T). Cache behaviour was my tentative conclusion but I didn't have time to investigate it further. I'm still hoping that the recent changes to the inlining interpreter will show gains on ARM.

Syndicated 2008-07-31 16:06:00 (Updated 2008-07-31 23:12:23) from Robert Lougher

Glastonbury!

Finally all ready for Glastonbury. Leave tomorrow morning, and should arrive around midday.

Finishing the welding took longer than expected (it always does). Two new shock absorbers and a couple of brake pipes and the camper passed the MOT on Friday.

Today, I replaced the oil strainer (old VW aircooled engines don't have a modern oil filter) and changed the oil. Decided to change from monograde 30 weight to a modern 15W-50 multigrade. Opinions differ as to which is best (VW recommended monograde back in the early 70s but multigrades have improved considerably since then). I've used monograde for 2 years and I'll see if it runs better.

Glastonbury should be fun, but I'm keen to get back to JamVM. I'm not taking a laptop!

Syndicated 2008-06-25 01:06:00 (Updated 2008-06-25 01:25:13) from Robert Lougher

5 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!