tag:blogger.com,1999:blog-3003887307822917702024-03-13T02:29:23.156+00:00TerminusRobert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-300388730782291770.post-18746125220158486772014-08-17T01:49:00.001+01:002014-08-17T01:49:57.980+01:00What No Comments?Thanks to everybody who commented on the JamVM 2.0.0 release, and apologies it's taken so long to approve them - I was expecting to get an email when I had an unmoderated comment but I haven't received any.<br />
<br />
To answer the query regarding Nashorn. Yes, JamVM 2.0.0 can run Nashorn. It was one of the things I tested the JSR 292 implementation against. However, I can't say I ran any particularly large scripts with it (it's not something I have a lot of experience with). I'd be pleased to hear any experiences (good or bad) you have.<br />
<br />
So now 2.0.0 is out of the way I hope to do much more frequent releases. I've just started to look at OpenJDK 9. I was slightly dismayed to discover it wouldn't even start up (java -version), but it turned out to be not a lot of work to fix (2 evenings). Next is the jtreg tests...<br />
<br />Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com0tag:blogger.com,1999:blog-300388730782291770.post-18087755254131000902014-08-01T01:46:00.000+01:002014-08-01T01:46:05.830+01:00JamVM 2.0.0 ReleasedI'm pleased to announce a new release of JamVM. JamVM 2.0.0 is the first release of JamVM with support for OpenJDK (in addition to GNU Classpath). Although IcedTea already includes JamVM with OpenJDK support, this has been based on periodic snapshots of the development tree.<br />
<br />
JamVM 2.0.0 supports OpenJDK 6, 7 and 8 (the latest). With OpenJDK 7 and 8 this includes full support for JSR 292 (invokedynamic). JamVM 2.0.0 with OpenJDK 8 also includes full support for Lambda expressions (JSR 335), type annotations (JSR 308) and method parameter reflection.<br />
<br />
In addition to OpenJDK support, JamVM 2.0.0 also includes many bug-fixes, performance improvements and improved compatibility (from running the OpenJDK jtreg tests).<br />
<br />
The full release notes can be found <a href="http://sourceforge.net/projects/jamvm/files/jamvm/JamVM%202.0.0/README/view">here</a> (changes are categorised into those affecting OpenJDK, GNU Classpath and both), and the release package can be downloaded from the <a href="http://sourceforge.net/projects/jamvm/files/jamvm/">file area</a>.<br />
<br />Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com6tag:blogger.com,1999:blog-300388730782291770.post-71803101407217432212012-12-31T23:03:00.000+00:002012-12-31T23:12:29.319+00:00The long and winding road of JSR 292As the biggest change to the JVM since the introduction of Java, I've been acutely aware that I can't ignore JSR 292 and simply leave it unimplemented in JamVM. This has been reinforced recently by announcements such as <a href="http://en.wikipedia.org/wiki/Nashorn_%28JavaScript_engine%29">Nashorn</a> that indicate that more and more developments in the future will require JSR 292.<br />
<br />
However, my record of implementing it has been dismal. I first started about this time last year (end of December 2011). At the time I hoped to get it finished for FOSDEM in February. This was a tall order, but by FOSDEM I had invokeExact working, and could run several simple examples (all with OpenJDK 7). I understood the general framework, and the way in which method handles were chained together (invocation involved following the chain, performing transformations along the way, until the final target method was reached).<br />
<br />
The problem was the number of transformations the VM needed to implement. Certain ones such as unboxing (REF_TO_PRIM) and retyping were straight-forward. But more complex ones such as argument spreading were extremely time consuming, and there were even more exotic ones requiring "ricochet frames" (I never did work out exactly what they were). Anyway, I didn't deliberately abandon the work, I just stopped and didn't touch JamVM for 6 months.<br />
<br />
The breakthrough came from reading Roman Kennke's blog of getting <a href="http://rkennke.wordpress.com/2012/08/08/hotspot-zero-openjdk8-davinci/">Zero working with OpenJDK 8</a>. Of particular interest was the removal of the adapter code from Zero (like JamVM, it was incomplete). It was no longer needed as the transformations are now done in Java, via LambdaForms. These are compiled into bytecodes via the JSR 292 runtime, again coded in Java.<br />
<br />
So the main stumbling block of my last attempt was gone. However, unlike with Zero, in addition to invokedynamic the rest of the JSR 292 support within the VM has to be implemented (class file changes, resolution of method handles/types, call site bootstrap methods, stack walking, field injection, etc.). It's taken a couple of weeks work, with a lot of debugging over Christmas (it's been so wet in the UK there's been nothing much else to do) but all but one of the jtreg tests for java.lang.invoke pass. In fact, all tests were passing until I updated my sources a few days ago and found an extra 6 tests.<br />
<pre>Passed: java/lang/invoke/6987555/Test6987555.java
Passed: java/lang/invoke/6991596/Test6991596.java
Passed: java/lang/invoke/6998541/Test6998541.java
Passed: java/lang/invoke/7157574/Test7157574.java
Passed: java/lang/invoke/7196190/ClassForNameTest.java
FAILED: java/lang/invoke/7196190/GetUnsafeTest.java
Passed: java/lang/invoke/7196190/MHProxyTest.java
Passed: java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
Passed: java/lang/invoke/lambda/LambdaAccessControlTest.java
Passed: java/lang/invoke/AccessControlTest.java
Passed: java/lang/invoke/BigArityTest.java
Passed: java/lang/invoke/CallSiteTest.java
Passed: java/lang/invoke/ClassValueTest.java
Passed: java/lang/invoke/InvokeDynamicPrintArgs.java
Passed: java/lang/invoke/InvokeGenericTest.java
Passed: java/lang/invoke/JavaDocExamplesTest.java
Passed: java/lang/invoke/MethodHandlesTest.java
Passed: java/lang/invoke/MethodTypeTest.java
Passed: java/lang/invoke/PermuteArgsTest.java
Passed: java/lang/invoke/PrivateInvokeTest.java
Passed: java/lang/invoke/RicochetTest.java
Passed: java/lang/invoke/ThrowExceptionsTest.java
Test results: passed: 21; failed: 1</pre>
The changes aren't pushed to git yet, as JamVM will currently only work with OpenJDK 8. Getting it to work with OpenJDK 6/7 (without JSR 292) won't be difficult, but GNU Classpath will be more tricky.<br />
<br />Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com4tag:blogger.com,1999:blog-300388730782291770.post-61854024958569949662011-12-30T01:09:00.002+00:002011-12-30T01:26:22.012+00:00JamVM no claim to notability?JamVM has a <a href="http://en.wikipedia.org/wiki/JamVM">wikipedia page</a>. I didn't create it, and I'm not egotistical enough to maintain it in any way. However, I was less than impressed to see that somebody had taken it upon themselves to put the page forward for <a href="http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/JamVM">deletion</a>. The reasons being that it hasn't had a recent release, and that it has no claim to notability.<br /><br />I have tried to show that neither of these claims are true. For example, JamVM is the default VM on Ubuntu/ARM 11.10. I think this is both notable and recent! However, this doesn't seem to count, the debate being fixated on a claim on the page regarding Dalvik from a blog.<br /><br />To be honest, I'm so disgusted with the process that I no longer care if the page is deleted. But if anybody else cares, please put a word in for JamVM.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com10tag:blogger.com,1999:blog-300388730782291770.post-14738384592155539972011-02-16T01:12:00.005+00:002011-02-16T03:31:20.843+00:00OpenJDK/JamVM Git repositoryJamVM's got a shiny new Git repository, which contains the port to the OpenJDK class-library. Details are here: <a href="http://developer.berlios.de/git/?group_id=6545">http://developer.berlios.de/git/?group_id=6545</a><br /><br />The repository can be checked out anonymously with:<br /><pre>git clone git://git.berlios.de/jamvm</pre>JamVM 1.6.0 will be released off of this in the near future. JamVM 1.6.0 will be a combined release, supporting both GNU Classpath and OpenJDK class-libraries, with GNU Classpath support being built by default. I still need to run some tests to make sure that the refactored codebase hasn't introduced any regressions w.r.t. GNU Classpath and JamVM 1.5.4.<br /><br />So what can be done with the OpenJDK port? As discussed in my <a href="http://wiki.debian.org/Java/DevJam/2011/Fosdem/JavaSpeakers#JamVM">FOSDEM</a> talk, it is ready for a first release. There's stuff which hasn't been implemented, but it runs everything I've tested it with (jedit, eclipse, derby, etc.).<br /><br />Some words on running the port. JamVM is not yet integrated into the IcedTea build process (although it supports the same --with-java-runtime-library switch as Cacao). Instead, the easiest way to test the port is to build JamVM, and copy the libjvm.so file into an existing IcedTea/OpenJDK installation.<br /><br />After cloning the git repository, do:<br /><pre>./autogen.sh --with-java-runtime-library=openjdk</pre>This will generate the autoconf/automake files and configure JamVM to build support for OpenJDK.<br /><br />Then do make, make install<span style="font-family:courier;"></span> as usual. This will put libjvm.so into /usr/local/jamvm/lib.<br /><br />This can then be copied onto an existing IcedTea installation (or a copy of one), e.g. on x86_64 (as root):<br /><pre>cd /usr/lib/jvm<br />cp -r java-6-openjdk jamvm-openjdk<br />cp /usr/local/jamvm/lib/libjvm.so jamvm-openjdk/jre/lib/amd64/server</pre>You can then run it by running the normal java wrapper, e.g.:<br /><pre><span style="font-size:100%;">/usr/lib/jvm/jamvm-openjdk/jre/bin/java -version<br /><br />java version "1.6.0_20"<br />OpenJDK Runtime Environment (IcedTea6 1.9.5) (6b20-1.9.5-0ubuntu1)<br />JamVM (build 1.6.0-devel, inline-threaded interpreter)</span></pre>(the inline-threaded interpreter is the other name for the code-copying JIT)Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com4tag:blogger.com,1999:blog-300388730782291770.post-11947821902077235412010-08-03T23:15:00.005+01:002010-08-04T00:47:35.893+01:00Debian Linux on cheap MIPS mini netbookComputing-wise, I've taken a break from the JamVM/OpenJDK port for a couple of days while I play with my latest toy : a cheap mini-netbook based on a Chinese MIPS clone. It's branded CnMbook, but it's available (or was) under <a href="http://en.wikipedia.org/wiki/Skytone_Alpha-400">dozens of names</a>.<br /><br />Yes, it's been available for a while. I first investigated it over a year ago as I wanted a MIPS machine on which I could do the port of the code-copying JIT (I did the MIPS port of JamVM back in 2007, and I've not touched it since). But it was 170 pounds, which was too much for the tiny spec, and I got an EeePC instead.<br /><br />However, I still don't like Intel, even though it finally became my main architecture in 2008 (albeit AMD). And I like it even less as a mobile processor, as it's the last area where it doesn't dominate.<br /><br />So what lead to this sudden surge of interest? I've been waiting for years for the fabled ARM-based netbooks, and a couple of weeks ago I saw a cheap WinCE mini-netbook in a local discount shop which I was passing. My brother (the author of <a href="http://en.wikipedia.org/wiki/Squashfs">SquashFS</a>) thought it shouldn't be too difficult to get Linux working on it. This lead to a weekend long investigation, which showed up some startling results.<br /><br />The mini-netbooks appear to be based on one of two ARM9-based SoCs (so these still aren't the low-cost Cortex A8 ones I've been waiting for). Either the Anyka AK7802 or Via's WonderMedia VT8505 SoC. The amazing thing? There's no publicly available Linux kernel (with source) for any of them. There is a binary-only Android kernel for the VT8505 but no public source. For the AK7802 there's nothing, and as Anyka have not made any SoC documentation publicly available it's likely that there never will be.<br /><br />In contrast, Ingenic, the maker of the MIPS clone in the CnMbook have made <a href="http://www.ingenic.cn/eng/productServ/kfyd/Linux/pfCustomPage.aspx">available</a> the full source to their modified kernel, u-boot bootloader, rootfs and applications. It came with CELinux, and an ancient 2.4.20 kernel. But it didn't take my brother long to get a modern-ish 2.6.24 kernel running on it (he's working on 2.6.31), and with Debian MIPS Linux it makes a nice little portable development system. Compiling is rather slow, but vim runs well on console, which is all you need!<br /><br />The cost? 65 quid off ebay for an ex-display model as you can't buy them anymore, the ARM9 WinCE machines having completely replaced them.<br /><br />I'll next post my experience of running JamVM/OpenJDK on it :)Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com1tag:blogger.com,1999:blog-300388730782291770.post-69022656988876132452010-07-27T00:19:00.002+01:002010-07-27T02:30:21.276+01:00... a thousand words (JamVM/OpenJDK update 2)Firstly apologies to the people who commented on my first progress update (18th May). I'd hoped to do a blog update <span style="font-style:italic;">way</span> before now, but I've had a lot less time to work on JamVM/OpenJDK port than I expected...<br /><br /><span style="font-weight:bold;">Xerces Ranby</span> asked:<br /><blockquote><span style="font-style:italic;">Does JamVM still produce those quick and fast startup times when using the OpenJDK class libraries compared to the fast startup times obtainable when using GNU Classpath classes?<br /></span></blockquote><span style="font-weight:bold;">[best of 3 runs]</span><br /><blockquote><span style="font-family:courier;">rob@traken:~/JAM/tests$ time /usr/lib/jvm/jamvm-openjdk/jre/bin/java -showversion hello<br />java version "1.6.0_0"<br />OpenJDK Runtime Environment (IcedTea6 1.6.1) (6b16-1.6.1-3ubuntu1)<br />JamVM (build 1.5.5-openjdk, inline-threaded interpreter)<br /><br />Hello World!<br /><br />real 0m0.046s<br />user 0m0.030s<br />sys 0m0.000s<br /><br />rob@traken:~/JAM/tests$ time jamvm -showversion hello<br />java version "1.5.0"<br />JamVM version 1.5.5-devel<br />Copyright (C) 2003-2010 Robert Lougher <rob@jamvm.org.uk><br />...<br />Build information:<br />Execution Engine: inline-threaded interpreter<br />Compiled with: gcc 4.5.0 20100211 (experimental)<br />Boot Library Path: /usr/local/classpath/lib/classpath<br />Boot Class Path: /usr/local/jamvm/share/jamvm/classes.zip:/usr/local/classpath/share/classpath/glibj.zip<br /><br />Hello World!<br /><br />real 0m0.048s<br />user 0m0.030s<br />sys 0m0.020s<br /></span></blockquote><br /><span style="font-weight:bold;">gnu_andrew</span> asked:<br /><blockquote><span style="font-style:italic;">Will JamVM still support GNU Classpath, as CACAO does?</span></blockquote>Yes, most definitely. I still consider GNU Classpath as JamVM's main class-library as it's where my chief loyalty lies. On more practical grounds, even after the OpenJDK port is functionally complete it will still be a long time before it is as tested as JamVM/GNU Classpath. FWIW, many embedded systems seem to be quite happy with GNU Classpath. GNU Classpath is considerably smaller "out of the box" and much easier to build...<br /><br />As far as development is concerned, I've taken a different approach to <span style="font-weight:bold;">Cacao</span>. Cacao implements the class-library differences within the VM-specific code using <span style="font-family:courier;">#ifdef</span>s. While there's nothing wrong with that, I personally think it makes the code harder to read, and it's harder to get an overview of the changes.<br /><br />Instead, I've tried to abstract the differences into a <span style="font-style:italic;">classlib interface</span>. At times this has taken some thought and quite a lot of code re-arranging. If anything it's made the code cleaner, as a lot of the messier details are hidden (in general, I'm not a fan of information hiding, but removal of some of the VMFoo details makes the intent clearer).<br /><br />Having said that, the classlib interface is mostly driven by the differences between GNU Classpath and OpenJDK as I find them. I'd like to think the interface is reasonably generic, but it will probably need changing if another class-library came along...<br /><br />Currently the classlib interface has 40 functions, the gnuclasspath directory has 8 files, totalling 2552 LOC, and openjdk 10 files totalling 3491 LOC.<br /><br /><span style="font-weight:bold;">Christian Thalinger</span> (hello, twisti!), <span style="font-weight:bold;">linuxhippy</span> (hello, Clemens!), <span style="font-weight:bold;">Michael Starzinger</span> (hello, Michi!), <span style="font-weight:bold;">Stefan Ring</span>:<br /><br />Yeah, it's taken a long time, and lots of prevaricating. It's not been <span style="font-style:italic;">quite</span> as boring and tedious as I expected; some of it I've actually enjoyed :) Debian might even re-instate JamVM (sticking pins in the Debian T-shirt I bought at FOSDEM, while looking for the Fedora 13 CDROM).Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com1tag:blogger.com,1999:blog-300388730782291770.post-14244668701278220472010-07-27T00:11:00.002+01:002010-07-27T00:15:47.486+01:00A picture is worth...<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguI418tF5QkjbDzE3Mpth64DvtRLcm-R3ZeJ6rxH1yKKuc1eX-S9s0m63LFdihnuug1Gk70X8fQ_vmYYOkFEEnp4iCrz1SGcnvwa0QhwG6PuN_lS4lrP1LUp7J-2oyXDMKF4DZ7hSAr1Rp/s1600/dump.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 325px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguI418tF5QkjbDzE3Mpth64DvtRLcm-R3ZeJ6rxH1yKKuc1eX-S9s0m63LFdihnuug1Gk70X8fQ_vmYYOkFEEnp4iCrz1SGcnvwa0QhwG6PuN_lS4lrP1LUp7J-2oyXDMKF4DZ7hSAr1Rp/s400/dump.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5498357345935226882" /></a>Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com1tag:blogger.com,1999:blog-300388730782291770.post-17164531587847808842010-05-18T00:36:00.006+01:002010-05-18T01:14:21.689+01:00JamVM and OpenJDK - Progess UpdatePorting JamVM to use the OpenJDK/IcedTea class-library has been on my TODO list for quite a while. It appears on my FOSDEM slides for 2008 and again in 2009. It doesn't this year, as I didn't do a talk. Maybe that's why I've finally got round to doing it. I told Twisti I'd get "Hello World" running in 3 months. I've missed by just over a week, mainly because I only started 2 months ago.<br /><blockquote><span style="font-family:courier;">root@traken:/usr/local/jamvm/bin# java -Xbootclasspath:/usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar -Dsun.boot.library.path=/usr/lib/jvm/java-6-openjdk/jre/lib/amd64 -showversion hello<br />java version "1.6.0_0"<br />OpenJDK Runtime Environment (IcedTea6 1.6.1) (6b16-1.6.1-3ubuntu1)<br />JamVM (build 1.5.5-openjdk, inline-threaded interpreter)<br /><br />Hello World!<br />root@traken:/usr/local/jamvm/bin#</blockquote></span><br />There's still quite a lot to do, including finishing off support for reflection and sun.misc.Unsafe but threading, exception handling, library handling, class-loading and the VM bootstrap sequence should be done.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com6tag:blogger.com,1999:blog-300388730782291770.post-7217746986262157802009-05-12T02:04:00.003+01:002009-05-12T15:11:42.711+01:00Netifera uses JamVM as remote probe<a href="http://netifera.com/">Netifera</a> 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".<br /><br />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:<br /><br /><a href="http://netifera.com/video/netifera_java_virtual_machine_as_shellcode">http://netifera.com/video/netifera_java_virtual_machine_as_shellcode<br /></a><br /><br />JamVM and GNU Classpath are mentioned starting 14:54 into the webcast in the discussion of the probe architecture.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com0tag:blogger.com,1999:blog-300388730782291770.post-55501501745597537042009-05-11T22:55:00.004+01:002009-05-12T01:53:32.603+01:00JamVM on Beagle BoardI'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...<br /><br />So far, the results are quite encouraging. SciMark 2.0 shows a 55% speed improvement:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwWzEk6iNPJQmlUQzDdfIgaXL5xybt2S26LBmd318YbDuF-TqdN3yqaBEiRCkAEOhQOXIx5UOOn3Sk4oFvgoF5i0sOVfeZ-cbK4oixgN6XX3bPxtStUvPA7c2qnawt6NOuJddP6Id0QzeO/s1600-h/img0.jpg"><img style="cursor:pointer; cursor:hand;width: 320px; height: 274px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwWzEk6iNPJQmlUQzDdfIgaXL5xybt2S26LBmd318YbDuF-TqdN3yqaBEiRCkAEOhQOXIx5UOOn3Sk4oFvgoF5i0sOVfeZ-cbK4oixgN6XX3bPxtStUvPA7c2qnawt6NOuJddP6Id0QzeO/s400/img0.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5334713890845418754" /></a><br /><br />While jBYTEmark shows an 82% improvement on Integer tests:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWZwRwIuAkJqSlIwBN0Znh2af7MJgI27Q0wwzI3puCe0D_mOvqu1yoK0Nk6njEhEWR55MjaZ7JlhTL54KGEQq8FnbKtlMYwOPCWJpl1E_9Ghb-17tB0udnWc7QeBXBsTR0cKj6wlE7g9Y_/s1600-h/img5.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 236px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWZwRwIuAkJqSlIwBN0Znh2af7MJgI27Q0wwzI3puCe0D_mOvqu1yoK0Nk6njEhEWR55MjaZ7JlhTL54KGEQq8FnbKtlMYwOPCWJpl1E_9Ghb-17tB0udnWc7QeBXBsTR0cKj6wlE7g9Y_/s400/img5.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5334731311447977858" /></a><br /><br />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.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com0tag:blogger.com,1999:blog-300388730782291770.post-11769842020552838982009-03-17T01:18:00.006+00:002009-03-17T10:42:55.572+00:00JRuby 1.2.0RC2I read with interest Jeroen's recent post on his <a href="http://weblog.ikvm.net/">blog</a> about his experiences running <a href="http://docs.codehaus.org/display/JRUBY/2009/03/06/JRuby+1.2.0RC2+Released">JRuby 1.2.0RC2</a> 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 <span style="font-weight:bold;">segv-ed</span>. This was the first of 5 problems.<br /><br />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 <span style="font-weight:bold;">JNI_OnUnload</span> function called back into Java.<br /><br />Basically, I didn't take into account libraries which have a <span style="font-weight:bold;">JNI_OnUnload</span> 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.<br /><br />The next problem was with <span style="font-weight:bold;">MemoryManagerMXBean</span>. I spent some time implementing native support for <span style="font-weight:bold;">ThreadMXBean</span> 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.<br /><br />After that there was a problem with annotations, where an <span style="font-weight:bold;">AnnotationTypeMismatchException</span> 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 <a href="http://gcc.gnu.org/ml/java-patches/2007-q1/msg00619.html">implementation</a> in gcj, so I was able to adapt the fix into JamVMs version of <span style="font-weight:bold;">sun.reflect.annotation.AnnotationInvocationHandler</span>.<br /><br />Problem number 4 was with <span style="font-weight:bold;">VMClassLoader.getPackage()</span>. The default GNU Classpath implementation relies on a META-INF/INDEX.LIST file existing in the first Jar in the bootclasspath. JRuby uses <a href="http://kenai.com/projects/constantine">Constantine</a>, 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.<br /><br />Finally, there was a problem with <span style="font-weight:bold;">Class.getSimpleName()</span>. 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 <a href="http://www.mail-archive.com/classpath-patches@gnu.org/msg10757.html">broken</a>. Again, I took the fix from gcj.<br /><br />After all this, jRuby runs!<br /><blockquote><span style="font-family:courier;">rob@dougal:~$ jruby hello.rb <br />Hello World!</span></blockquote><br />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.<br /><blockquote><span style="font-family:courier;">rob@dougal:~$ jirb --prompt simple<br />trap not supported or not allowed by this VM<br />>> include_class java.lang.System<br />include_class java.lang.System<br />=> Java::JavaLang::System<br />>> System.getProperty("java.vm.name")<br />System.getProperty("java.vm.name")<br />=> "JamVM"<br />>> System.getProperty("java.vendor")<br />System.getProperty("java.vendor")<br />=> "GNU Classpath"<br />>> quit<br />quit</span></blockquote>Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com4tag:blogger.com,1999:blog-300388730782291770.post-55636391789582032062009-03-02T00:41:00.010+00:002009-03-02T02:47:54.330+00:00BenchmarksA couple of people after my <a href="http://wiki.debian.org/Java/DevJam/2009/Fosdem?action=AttachFile&do=get&target=Robert-JamVM.pdf">talk</a> 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.<br /><br />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.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj22iuxPA8U1mVb3ona2-xxYA91RmU65p564UXFdiWY-XIXuedxecWigYpElqg3E1qPrhCm8nzBtSBdFka4ZrHXQ0GeeB451UeS3g_SMlZYS41szoaD-o0HsL6vEH2DLq_B9ndH104k1EuJ/s1600-h/chart2.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 221px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj22iuxPA8U1mVb3ona2-xxYA91RmU65p564UXFdiWY-XIXuedxecWigYpElqg3E1qPrhCm8nzBtSBdFka4ZrHXQ0GeeB451UeS3g_SMlZYS41szoaD-o0HsL6vEH2DLq_B9ndH104k1EuJ/s400/chart2.jpg" alt="" id="BLOGGER_PHOTO_ID_5308415330513888578" border="0" /></a>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+.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com2tag:blogger.com,1999:blog-300388730782291770.post-63505813995367466502008-12-09T20:13:00.005+00:002008-12-09T22:12:51.122+00:00BUG Labs JVM saga end gameI've been following <a href="http://www.buglabs.net">Bug Labs</a> choice of JVM quite closely. After a series of comparisons between JamVM, CacaoVM and PhoneME they adopted PhoneME (initial test <a href="http://bugblogger.com/java-vms-compared-160/">here</a> <span style="text-decoration: underline;"></span>and the <a href="http://bugblogger.com/java-vms-compared-ii-187/">follow-up</a>). I <a href="http://draenog.blogspot.com/2008/07/embedded-jvm-comparison.html">blogged</a> 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.<br /><br />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.<br /><br />So, I read with great interest the recent <a href="http://community.buglabs.net/kgilmer/posts/37-CACAO-GNU-Classpath-on-BUG">blog</a> 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.<br /><br />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.<br /><br />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).<br /><br />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 <a href="http://server.complang.tuwien.ac.at/cgi-bin/bugzilla/show_bug.cgi?id=32">memory fragmentation issues</a>, and it has no support for soft/weak/phantom references or class-unloading.<br /><br />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".<br /><br />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).<br /><br />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.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com3tag:blogger.com,1999:blog-300388730782291770.post-65629828850681921212008-11-17T17:04:00.006+00:002008-11-17T19:02:10.749+00:00JamVM/GNU Classpath/iPhone roundupIt's a year since JamVM was <a href="http://gnu.wildebeest.org/diary/2007/11/22/free-your-iphone/">ported</a> to the iPhone/iPod Touch. A quick browse on Google shows up a couple of interesting things:<br /><ul><li><a href="http://knopflerfish.blogspot.com/2008/09/knopflerfish-osgi-on-ipod-touchiphone.html">Running Knopflerfish OSGi</a></li><li><a href="http://yusuke.homeip.net/blog/2008/08/24/running_jboss_on_iphone.html">Running JBoss</a> (minimal configuration)</li></ul>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 <a href="http://journal.mycom.co.jp/column/osx/286/index.html">Japanese</a>, but the bar chart at the end is clear.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com0tag:blogger.com,1999:blog-300388730782291770.post-90192164200095957892008-11-16T20:54:00.005+00:002008-11-16T21:59:11.865+00:00Lend 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:<br /><blockquote>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?</blockquote>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?<br /><br />* With apologies to Jethro Tull.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com9tag:blogger.com,1999:blog-300388730782291770.post-59775594486091405332008-07-31T17:06:00.004+01:002008-08-01T00:12:23.362+01:00Embedded JVM comparison<a href="http://buglabs.net/">Buglabs</a> 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 <a href="https://phoneme.dev.java.net/content/phoneme_advanced_r2.html">PhoneME advanced</a>, <a href="http://cacaojvm.org/">Cacao</a> and <a href="http://jamvm.org/">JamVM</a>. The results are very interesting :<br /><br /><a href="http://bugblogger.com/java-vms-compared-160/">http://bugblogger.com/java-vms-compared-160/</a><br /><br />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).<br /><br />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.<br /><br />The benchmarks used in the test are dominated by floating point. Looking at the <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0211j/I1000175.html">Technical Reference Manual</a> 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.<br /><br />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.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com4tag:blogger.com,1999:blog-300388730782291770.post-35783047149565712442008-06-25T02:06:00.002+01:002008-06-25T02:25:13.402+01:00Glastonbury!Finally all ready for Glastonbury. Leave tomorrow morning, and should arrive around midday.<br /><br />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.<br /><br />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.<br /><br />Glastonbury should be fun, but I'm keen to get back to JamVM. I'm not taking a laptop!Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com0tag:blogger.com,1999:blog-300388730782291770.post-1423662366391293972008-06-12T02:22:00.002+01:002008-06-12T03:28:19.958+01:00Flowers in your hair (or at least on your camper)It's now a month since I finished working. I still have no regrets leaving -- this is the first real time I've had off for 4 and a half years, and I've only made a small dent in the amount of work that's built up in the last few years. In total, I've been working away from home for the past 7 years, and I'm getting to the age where I can't do it any longer.<br /><br />Having said that, I will soon have to think about finding another job. I don't want to live off my savings for more than a few months. Maybe to the end of the summer. But I need to start to consider my options (which at present is not very much).<br /><br />So what have I been doing for the last month? I've been restoring my old 1972 VW camper (it's almost as old as I am). I did quite a lot of welding for the MOT last year but the final finishing up was rushed due to lack of time. I've got yet more to do for the MOT this year, which is up just before Glastonbury (a long running music festival, for the non-UK readers). Taking an old hippy-wagon to Glastonbury is a lot of fun (I'm thinking about putting on a load of stick-on flowers for this year).<br /><br />Last week I finished respraying the front in its original colours (orient blue over pastel white) and replaced the spare tyre with a VW symbol. This required longer than expected because the front panel needed welding and a new panel had to be welded in the left corner (it was all filler).<br /><br />Tomorrow, I've got to finish removing the near-side inner sil, weld in a new one, and replace the rear jacking point. Then I've got to start on the outer sil. It should then be ready for the MOT (only 8 days remaining). I replaced the front jacking points and outriggers last year.<br /><br />So what about JamVM? I'm still working on it in the evenings, as if I was still working. I'm currently still bogged down in a load of inlining interpreter optimisations that I've been prototyping for the last few months. I've now got to put everything back together and tidy things up for a release. With testing, this is still at least a month or so away.<br /><br />Contrary to my previous posts, I'm no longer thinking about giving JamVM up. I've decided I do get sufficient "return" for my time to make it worthwile. Giving your time away for free when there's no money coming in is difficult, but I don't want to end up just another odd-jobber doing up his camper.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com1tag:blogger.com,1999:blog-300388730782291770.post-85452254073081821582008-04-28T16:07:00.006+01:002008-04-28T18:01:27.348+01:00Third time lucky?In JamVM 1.5.0 I released the "inlining interpreter" which copies code blocks together in a similar way to a simple JIT (but the code is compiled by gcc, rather than being generated natively as in a JIT). This achieved an impressive speed improvement and I've been keen to optimise it further.<br /><br />The major thing which has been in my sights is the remaining dispatches between adjacent basic blocks. For instance the fallthrough edge of an "if" and across the edge caused by a jump target.<br /><br />Currently, the unit of inlining is a basic block because this has only one entry point and one exit point. Blocks which contain instructions which need to be rewritten (quickening, e.g. after symbolic resolution) must be executed first using threaded dispatch. If we inlined across blocks we will end up with blocks with multiple entry and multiple exit points. In this case, depending on control flow, we may complete the block before all the block has been executed, or we may never reach the end of the block because a side exit is always taken. In the first case, inlining can't be done, and in the second inlining will never occur.<br /><br />My first approach to solve this was simplistic, and was more of an experiment to "test the water". So I wasn't too surprised when it didn't yield any speed improvement.<br /><br />My second attempt was much more complex (after inlining check the edges and create a longer block if the blocks across the edge are both inlined, and fix up internal targets). But this showed no significant general speed improvement (order of 2%) although specific microbenchmarks showed over 100%.<br /><br />So for the last week I've been trying to explain the results. After some experiments I've come to the conclusion that it is due to instruction cache locality. Basically, the merged block (which may be merged many times) ends up in a different location to the non-mergeable blocks which remain in the initial position. Previously, inlining exhibited good cache locality due to blocks being allocated in execution order. This was destroyed by block merging. The effects of this counteracted the speed improvements leading to no change overall.<br /><br />This was the position I was in on Friday (which added to my despondency). However, on the weekend I rethought the problem and came up with a third approach. I've partially implemented it and hopefully should be able to test it in a few days. Fingers crossed!Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com0tag:blogger.com,1999:blog-300388730782291770.post-8894601298722532062008-04-28T15:35:00.002+01:002008-04-28T16:05:16.000+01:00JamVM : back on the mapI feel like a kid who's thrown a tantrum and been rewarded with an ice-cream. In my last post I really thought I was asking a "serious and legitimate question" but it's difficult not to squirm when you get the praise you were secretly hoping for...<br /><br />So I'm grateful to all those who replied. JamVM is firmly back on the map :)Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com0tag:blogger.com,1999:blog-300388730782291770.post-42518705370315854442008-04-25T17:29:00.002+01:002008-04-25T18:40:06.064+01:00JamVM : road to nowhere?Change logs and development notes never give any insight into the wider whys and wherefores of a project. Perhaps that's for the better; stick to the facts, that's what engineers are good at. But as this is my first real post on JamVM (now that I know everything is working) I think it's appropriate.<br /><br />I started JamVM because I stopped being paid to work on proprietary VMs (after leaving a suitable gap). Because of worries of tainting I started my own VM rather than helping out on another. For the same reason I never directly contributed to GNU Classpath either. Of course, I wanted to make it smaller than any other, and I also wanted to make it open-source.<br /><br />I work on JamVM because I enjoy it. It's also nice to get the (occasional) positive email from users, and to see people using it on a whole variety of hardware. The download statistics are also still going up (last month downloads from sourceforge was over 1000 for the first time, and this doesn't include all the distros that package it and embedded buildroots).<br /><br />The problem is I sometimes wonder whether I'm flogging a dead horse and I'd be better off contributing my time to something else. I'm not trying to throw my toys out of the pram either; this is a serious and legitimate question.<br /><br />Of course, the reason is OpenJDK and to a lesser extent PhoneME. Java is now open-sourced, mostly unencumbered and finally packaged. At best am I wasting my time, and at worst am I fragmenting and confusing things? Opinions, dear readers, gratefully received.<br /><br />I discussed this with Jeroen Frijters at FOSDEM. In danger of misrepresenting things due to alcohol abuse, the general upshot was "why care?". If you still enjoy doing it, then do it. So I am.Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com14tag:blogger.com,1999:blog-300388730782291770.post-3224332200156599632008-04-25T15:34:00.000+01:002008-04-25T15:41:26.250+01:00First Post!With the orbits of the Java planets colliding I've decided it's about time that JamVM got a blog! It's only taken 5 years :)Robert Lougherhttp://www.blogger.com/profile/03530610982365125787noreply@blogger.com0