GNU Classpath

sudo opcontrol --reset sudo opcontrol --start # the thing you want to profile sudo opcontrol --stop opreport -l | less

During the last couple of weeks, I brought the Zero (i.e. no-assembly) interpreter of OpenJDK up-to-date with OpenJDK8 and (most of) the DaVinci project. Zero is not usually built in standard and developer builds of OpenJDK, and thus often falls by ... [More] the wayside when new features are developed in Hotspot. Various fixes needed to be made in order to be able to build and run Zero with the latest developments in OpenJDK8 and the DaVinci project again: The Makefiles needed to be updated for copying the .debuginfo and/or .diz files into the right places. Various small and fairly obvious changes needed to be made like renamed or extended method names. (Some of them are not only needed for Zero, even the X86 CPP interpreter was broken.) With those changes in place (with help from Chris Phillips), it was possible to build Zero with OpenJDK8. The next big step for me was to make Zero build with the DaVinci patch set, in particular with the meth-lazy-7023639.patch. This turned out to be a fairly large refactoring. This patch introduced the so-called lambda-forms for method handles, which moves most of the invocation logic into Java code. The method handles now generate synthetic methods to implement the invocation logic on-the-fly and call that, instead of implementing all of it in the VM. The most important changes that I made was: Rewrote the interpreter handler for the invokedynamic instruction. It now basically resolves the call site and the lambda form to call, and calls it. Implement a handler for the new invokehandle instruction. This is a JVM-internal bytecode that is generated for calls to the various intrinsics (see below), which pushes an optional appendix parameter on top of the interpreter stack, which is then consumed by those intrinsics and is basically a pointer to the target method to call. Implement 5 new intrinsics for MethodHandle: invokeBasic(), linkToStatic(), linkToSpecial(), linkToVirtual() and linkToInterface(). The first one is used to call into a lambda form using a polymorphic signature. The latter 4 call out to the target method and are basically signature-polymorphic versions of the various invoke* bytecodes. With those changes in place I can now build a Zero version of OpenJDK8 with the DaVinci (MLVM) patches and all jtreg tests for java/lang/invoke are passing now. As a very welcome side effect, I was able to throw out a *lot* of convoluted code for invokedynamic support in the interpreter. The new code is fairly simple and straightforward (and thus, more maintainable) instead. The code is available from a personal repository for now (it’s a forest-clone of the upstream hotspot-comp forest, with MQ patch queues in hotspot and jdk modules). In order to check it out, do this (you need the mq extension):   hg clone http://icedtea.classpath.org/people/rkennke/hotspot-comp-zero/ cd hotspot-comp-zero sh get-source.sh cd hotspot hg qpush -a cd ../jdk hg qpush -a cd .. Then build with Zero enabled, see my build script to get an overview of the build variables. [Less]

JSR 310 intends itself to take advantage of some Lambda features and the next step is to create a repository for integrating the JSR 310 APIs based on the Lambda runtime. Stay tuned...Roger Riggs, co-spec lead on JSR 310 in a post on the lambda-dev mailing list.

In the last episode of the Java Spotlight podcast, we interviewed Jonathan Giles, tech lead in Oracle's JavaFX UI controls team, on JavaFX 2.2 UI Controls.As usual, you can grab just this episode or fetch the whole feed.

IcedTea-Web 1.1.6 and 1.2.1 have now been released. In addition to bug fixes, they include 2 security fixes and it is therefore recommended that everyone upgrade to this release. The security issues fixed are: RH840592, CVE-2012-3422: Use of ... [More] uninitialized instance pointers RH841345, CVE-2012-3423: Incorrect handling of non 0-terminated strings Other fixes are listed in the NEWS files: 1.1.6 NEWS file 1.2.1 NEWS file The following people helped with these releases: Danesh Dadachanji Adam Domurad Omair Majid Saad Mohammad Jiri Vanek Checksums: 2e330475fdcd1a83b3f411a1aa475d8d45c585842444d20bb9160bed689dc1f1 icedtea-web-1.1.6.tar.gz 134efcd429086a643ba03ec6e4da991527c3e5dfcd6ed6680a83824ad3f0cfd6 icedtea-web-1.2.1.tar.gz Download links: http://icedtea.classpath.org/download/source/icedtea-web-1.1.6.tar.gz http://icedtea.classpath.org/download/source/icedtea-web-1.2.1.tar.gz After extracting, it can be built as per instructions here: http://icedtea.classpath.org/wiki/IcedTea-Web#Building_IcedTea-Web [Less]

Robert Lougher have updated JamVM to work on the new Raspberry PI armhf “Raspbian” image, thank you Robert! You can compile and test this latest JamVM version from source on a Raspberry PI by running the following lines inside a terminal: sudo ... [More] apt-get install openjdk-6-jdk git libtool autoconf automake git clone git://git.berlios.de/jamvm cd jamvm ./autogen.sh –with-java-runtime-library=openjdk make mkdir /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jamvm sudo cp src/.libs/libjvm.so /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jamvm/ sudo sed -i ‘s#-jamvm ERROR#-jamvm KNOWN#’ /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jvm.cfg java -jamvm -version java version “1.6.0_24″OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-2+rpi1)JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching) I will update IcedTea to include this updated version of JamVM. Distributions like Debian/Fedora/Ubuntu/Arch and Raspbian will get this new work when they update IcedTea to include the next IcedTea release or security update. This is the first JamVM + OpenJDK update in 2012, this update also include support for JamVM to run the QT-Jambi GUI toolkit. [Less]

I recently started working on Hotspot, with the goal of getting the Zero port up-to-date with respect to he recent developments in MLVM. In order to work most efficiently, I set up a work environment in Eclipse, and thought it’d be useful to share a ... [More] little HOW-TO. First of all, you need to install Eclipse/CDT if you haven’t already. This gives you a very powerful C/C++ development environment in Eclipse. You can then open an OpenJDK source tree as C/C++ project by selecting: File -> New -> Other and then ‘C/C++’ -> ‘Makefile project with existing code’. Enter project name, e.g. OpenJDK8, and the path to the existing location. Select the appropriate ‘Toolchain for indexer Settings’ below. Click Finish. Then open the project properties by right-clicking on the project, and selecting ‘Properties’. There we need to setup a couple of things.Under ‘C/C++ Build’ -> Environment, enter all environment variables that you would normally set on the command line for building OpenJDK. At the very least, you need ‘ALT_BOOTDIR’ and LANG=C. Under ‘C/C++ Build’, click the tab ‘Refresh Policy’ and remove the only path that is there (otherwise the whole workspace will be refreshed after a build, which takes looooong’). Optionally, add any paths under ‘build’ that you are interested in. Under ‘C/C++ General’ -> ‘Paths and Symbols’, select the tab ‘Source Location’ and remove the toplevel project path, and enter any source paths you are working with (e.g. hotspot/src). This limits what is visible to the indexer, etc. In order to take full advantage of Eclipse for debugging, I also changed ‘C/C++ Build’, ‘Behavior’ tab, replace ‘all’ with ‘debug_build’ This will normally do a debug build of OpenJDK, which means that you get all the symbols and no compiler optimizations in the binaries. In order to be able to load the symbols in gdb, add ‘ZIP_DEBUGINFO_FILES=0′ into the environment variables.Then click ‘Apply’ and ‘OK’ to close the settings dialog. Select ‘Project -> Build Project’ to launch the first build of OpenJDK in Eclipse. Debugging with Eclipse is similarily straightforward, open Debug Configurations, add a new C/C++ application, set up its properties for the binary, arguments and environment variables (make sure you use a debug-build binary) and run the thing! Being able to fully debug in Eclipse, navigating stack, inspecting variables, setting breakpoints and stepping through the code is so much more useful than doing the same in plain GDB:     [Less]

RESTful APIs tend to be written for use by other programs, but sometimes you just want to do some testing from the command line. This has a surprising number of gotchas; using curl or wget is harder than it should be. Wget Wget is the old standby ... [More] , right? Does everything you’d ever want it to. Bit of minor tweaking to get it not to blab on stdout about what it’s resolving (-q) and meanwhile telling it to just print the entity retrieved to stdout rather than saving it to a file (-O -) is easy enough. Finally, I generally like to see the response headers from the server I’m talking to (-S) so as to check that caching and entity tags are being set correctly: $ wget -S -q -O - http://server.example.com/resource/1 HTTP/1.1 200 OK Transfer-Encoding: chunked Date: Fri, 27 Jul 2012 04:49:17 GMT Content-Type: text/plain Hello world So far so good. The thing is, when doing RESTful work all you’re really doing is just exercising the HTTP spec, admittedly somewhat adroitly. So you need to be able to indicate things like the media type you’re looking for. Strangely, there’s no command line option offered by Wget for that; you have to specify the header manually: $ wget -S -q --header "Accept: application/json" -O - http://server.example.com/resource/1 HTTP/1.1 200 OK Date: Fri, 27 Jul 2012 04:55:50 GMT Cache-Control: max-age=42 Content-Type: application/json Content-Length: 27 { "text": "Hello world" } Cumbersome, but that’s what we wanted. Great. Now to update. This web service wants you to use HTTP PUT to change an existing resource. So we’ll just figure out how to do that. Reading the man page. Hm, nope; Wget is a downloader. Ok, that’s what it said it was, but I’d really come to think of it as a general purpose tool; it does support sending form data up in a POST request with it’s --post-file option. I figured PUT would just be lurking in a hidden corner. Silly me. Curl Ok, howabout Curl? Doing a GET is dead easy. Turn on response headers for diagnostic purposes (-i), but Curl writes to stdout by default, so: $ curl -i http://server.example.com/resource/1 HTTP/1.1 200 OK Transfer-Encoding: chunked Date: Fri, 27 Jul 2012 05:11:00 GMT Content-Type: text/plain Hello world but yup, we’ve still got to mess around manually supplying the MIME type we want; at least the option (-H) is a bit tighter: $ curl -i -H "Accept: application/json" http://server.example.com/resource/678 HTTP/1.1 200 OK Date: Fri, 27 Jul 2012 05:12:32 GMT Cache-Control: max-age=42 Content-Type: application/json Content-Length: 27 { "text": "Hello world" } Good start. Ok, what about our update? It’s not obvious from the curl man page, but to PUT data with curl, you have to manually specify the HTTP method to be used with (-X) and then (it turns out) you use the same -d parameter as you would if you were transmitting with POST: $ curl -X PUT -d name=value http://server.example.com/resource/1 $ That’s nice, except that when you’re PUTting you generally are not sending “application/x-www-form-urlencoded” name/value pairs; you’re sending actual content. You can tell Curl to pull from a file: $ curl -X PUT -d @filename.data http://server.example.com/resource/1 or, (at last), from stdin like you’d actually expect of a proper command line program: $ curl -X PUT -d @- http://server.example.com/resource/1 You are here. And then you aren't. ^D $ That was great, except that I found all my newlines getting stripped! I looked in in the database, and the content was: You are here. And then you aren't. Bah. After writing some tests server-side to make sure it wasn’t my code or the datastore at fault, along with finally resorting to hexdump -C to find out what was going on, I finally discovered that my trusty \n weren’t being stripped, they were being converted to \r. Yes, that’s right, mind-numbingly, Curl performs newline conversion by default. Why oh why would it do that? Anyway, it turns out that -d is short for --data-ascii; the workaround is to use --data-binary: $ curl -X PUT --data-binary @- http://server.example.com/resource/1 “oh,” he says, underwhelmed. But it gets better; for reasons I don’t yet understand, Curl gets confused by EOF )as indicated by typing Ctrl+D in the terminal). Not sure what’s up with that, but trusty 40 year-old cat knows what to do, so use it as a front end: $ cat | curl -X PUT --data-binary @- http://server.example.com/resource/1 Goodbye ^D $ The other thing missing is the MIME type you’re sending; if for example you’re sending a representation in JSON, you’ll need a header saying so: $ cat filename.json | curl -X PUT --data-binary @- -H "Content-Type: application/json" http://server.example.com/resource/1 { "text": "Goodbye cruel world" } ^D $ which is all a bit tedious. Needless to say I’ve stuck that in a shell script called (with utmost respect to libwww-perl) PUT, taking content type as an argument: $ ./PUT "application/json" http://localhost:8000/resource/1 < filename.json HTTP/1.1 204 Updated Server: Snap/0.9.1 Date: Fri, 27 Jul 2012 04:53:53 GMT Cache-Control: no-cache Content-Length: 0 $ Ah, that’s more like it. AfC [Less]

As some people may have noticed in the release notes of the last IcedTea release (2.2), Zero has become broken. This is because Zero does not yet support some of the changes made in HotSpot 23 and later. Chris Phillips and Andrew Haley at Red ... [More] Hat, now joined by Roman Kennke as well, are hard at work on fixing this as quickly as possible. In the interim, we’re providing a temporary solution which will at least get Zero working again, if not with all the new features of HotSpot 23 & 24. In this changeset, I updated IcedTea to download the HotSpot from the 2.1 branch instead, when Zero is enabled. Unfortunately, this doesn’t work out of the box. Although HotSpot is designed to be backwards compatible with older JDKs, the reverse is not true, so a number of backports were necessary to get it working. Namely: 7089790 (the BSD changes) 7098194 (the Mac OS X changes) 7116189 (expose JVM_SetNativeThreadName added in 7098194) 6924259 (change of fields in java.lang.String) 7175133 (fix jinfo post-6924259) While the first three were fairly obvious (the build fails because it can’t link against JVM_SetNativeThreadName), the String issue resulted in quite a bit of debugging as the JDK would build, but crash immediately on initialisation, which turned out to be when it was creating String instances for properties using the platform character set. You can try out Zero now by checking out IcedTea7 HEAD and building using the --enable-zero option. You should end up with something like: java version "1.7.0_06" OpenJDK Runtime Environment (IcedTea7 2.3pre+r7d3000c44b3b+) OpenJDK 64-Bit Zero VM (build 22.0-b10, interpreted mode) It was able to build itself and passed most HotSpot jtreg tests (available by make check-hotspot). The ones that didn’t pass timed out, presumably due to Zero’s slow speed. So Zero will work again in 2.3, using this support, and hopefully in the future, we’ll be able to have Zero on more recent HotSpot versions. Footnote: I’ve just found out, via a blog linkback, that Slackware package IcedTea. Always good to know where our work ends up! [Less]

With Szegedi’s move over to Oracle, some thought that this project wouldn’t be heading anywhere anytime soon but we’re glad to see that this couldn’t be any further from the truth. Szegedi says he was brought into Oracle “with the specific mandate of ... [More] making the Java platform a welcoming environment for non-Java languages,” which is incredibly encouraging to hear.An extract from Attila Szegedi's Dynalink 0.3 announcement being quoted in a jaxenter article by Chris Mayer titled "Dynalink 0.3 - JVM dynamic linking simplified". [Less]