rlougher is currently certified at Master level.

Name: Robert Lougher
Member since: 2005-04-11 01:54:49
Last Login: 2009-03-17 12:38:37

FOAF RDF Share This

Homepage: jamvm.sourceforge.net

Recent blog entries by rlougher

Syndication: RSS 2.0

What 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.

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.

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...

Syndicated 2014-08-17 00:49:00 (Updated 2014-08-17 00:49:57) from Robert Lougher

JamVM 2.0.0 Released

I'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.

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.

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).

The full release notes can be found here (changes are categorised into those affecting OpenJDK, GNU Classpath and both), and the release package can be downloaded from the file area.

Syndicated 2014-08-01 00:46:00 (Updated 2014-08-01 00:46:05) from Robert Lougher

31 Dec 2012 (updated 1 Jan 2013 at 00:09 UTC) »

The long and winding road of JSR 292

As 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 Nashorn that indicate that more and more developments in the future will require JSR 292.

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).

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.

The breakthrough came from reading Roman Kennke's blog of getting Zero working with OpenJDK 8.  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.

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.

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
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.

Syndicated 2012-12-31 23:03:00 (Updated 2012-12-31 23:12:29) from Robert Lougher

JamVM no claim to notability?

JamVM has a wikipedia page. 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 deletion. The reasons being that it hasn't had a recent release, and that it has no claim to notability.

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.

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.

Syndicated 2011-12-30 01:09:00 (Updated 2011-12-30 01:26:22) from Robert Lougher

16 Feb 2011 (updated 16 Feb 2011 at 04:14 UTC) »

OpenJDK/JamVM Git repository

JamVM's got a shiny new Git repository, which contains the port to the OpenJDK class-library. Details are here: http://developer.berlios.de/git/?group_id=6545

The repository can be checked out anonymously with:

git clone git://git.berlios.de/jamvm
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.

So what can be done with the OpenJDK port? As discussed in my FOSDEM 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.).

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.

After cloning the git repository, do:
./autogen.sh --with-java-runtime-library=openjdk
This will generate the autoconf/automake files and configure JamVM to build support for OpenJDK.

Then do make, make install as usual. This will put libjvm.so into /usr/local/jamvm/lib.

This can then be copied onto an existing IcedTea installation (or a copy of one), e.g. on x86_64 (as root):
cd /usr/lib/jvm
cp -r java-6-openjdk jamvm-openjdk
cp /usr/local/jamvm/lib/libjvm.so jamvm-openjdk/jre/lib/amd64/server
You can then run it by running the normal java wrapper, e.g.:
  /usr/lib/jvm/jamvm-openjdk/jre/bin/java -version

java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.5) (6b20-1.9.5-0ubuntu1)
JamVM (build 1.6.0-devel, inline-threaded interpreter)
(the inline-threaded interpreter is the other name for the code-copying JIT)

Syndicated 2011-02-16 01:12:00 (Updated 2011-02-16 03:31:20) from Robert Lougher

19 older entries...

 

rlougher certified others as follows:

  • rlougher certified ploppy as Master
  • rlougher certified twisti as Master
  • rlougher certified mjw as Master
  • rlougher certified michi as Master
  • rlougher certified ade as Apprentice

Others have certified rlougher as follows:

  • ploppy certified rlougher as Master
  • michi certified rlougher as Master

[ Certification disabled because you're not logged in. ]

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!

X
Share this page