JSR 292 and Zero

Maybe you’ve heard about JSR 292: Supporting Dynamically Typed Languages on the Java™ Platform? Well, it’s VM changes, and slated for OpenJDK 7 so I figured I ought to take a look at it before it suddenly appears and breaks Zero all over the place.

I’ve been working on it for a couple of weeks now over in the old Shark forest. It’s by no means stable, but if you want to have a play with it then here’s how:

1. Build yourself a recent(ish) copy of OpenJDK 7, one that has the JSR 292 stuff in the class library. I had a copy of the jdk7-hotspot-comp forest lying around, so I used that, but I expect you could use IcedTea7:

   hg fclone http://hg.openjdk.java.net/jdk7/hotspot-comp
   cd hotspot-comp
   export ALT_JDK_IMPORT_PATH=/path/to/some/existing/jvm
   export ALT_BOOTDIR=$ALT_JDK_IMPORT_PATH
   export DISABLE_NIMBUS=true
   export ALLOW_DOWNLOADS=true
   . jdk/make/jdk_generic_profile.sh
   make

2. Maybe go and have a cup of coffee while it builds…
3. Clone yourself a copy of the Shark forest:

   hg fclone http://icedtea.classpath.org/hg/shark

4. Edit the Makefile in there, changing JAVADIR to point to the JVM you just built.
5. Also change JUNITJAR to point to a JUnit 4 jarfile. The location there is where the Fedora junit4 package puts it, so if you have that installed you should be ok.
6. If you aren’t building on x86_64 then you’ll need to edit build.sh too. Set ZERO_LIBARCH, ZERO_ENDIANNESS, ZERO_ARCHDEF and ZERO_ARCHFLAG to appropriate values for your system.
7. Run make.

If you got your editing right it’ll build a new HotSpot, and create a copy of the JVM you built with the new HotSpot dropped in. It’ll then run the OpenJDK 7 JSR 292 unit tests on it.

They’ll fail, of course. Currently there’s no support for invokedynamic yet: I’m still working on the method handles code that underpins it. Method handles look like ordinary methods, except when you call a method handle the VM is presented with a chain of transformations that need applying to the call’s arguments and return value to translate between what the caller supplied and what the eventual callee is expecting. The bad news is that there are some 40 (!) different transformations, of which I’ve implemented maybe 15. The good news is that (I think!) I’ve figured out the framework of it all, so now it’s mostly a case of run the code, read the “unimplemented” message it spits out, and implement the thing it was complaining about. Just like the old days :)