FOSDEM is one of those rare events in my life about which I can say that it had a very significant impact. I wouldn’t be where I am today, if I hadn’t attended it a few years ago. I am very happy that I can finally go there again, and meet lots of old and new friends and collegues. See you there, and cheers!

However, what is the more important news is that after the release, I fixed Cacio-Web to work with the latest Cacio build and enabled it in the default build so it doesn’t fall to the wayside again. On popular request I would like to summarize how to get Cacio-Web running. Note that this currently only works on Linux (patches to enable this on other platforms are welcome!)

First of all, check out the source code (the cacio-web changes are not yet released):

hg clone http://hg.openjdk.java.net/caciocavallo/ng/ caciocavallo

Then build it (you need Maven!):

cd caciocavallo
mvn clean install

And finally you should be able to run with with something like this:

java -Dcacio.web.port=9091 -cp cacio-web/target/cacio-web-1.4-SNAPSHOT-jar-with-dependencies.jar:/home/rkennke/src/test/SwingSet2.jar net.java.openjdk.cacio.server.CacioServer

The -Dcacio.web.port parameter specifies on which port should Cacio-Web listen. Notice that the classpath needs to include your application (SwingSet2.jar in this case).

Then point your browser to a URL like this:

http://localhost:9091/SessionInitializer?cls=SwingSet2

Where the parameter cls specifies the (fully qualified) name of the main class of the application to start.

Please let me know if you run into any problems.

svn co http://llvm.org/svn/llvm-project/llvm/branches/release_32/ llvm-3.2
cd llvm-3.2
./configure && make && make install

Then you need to check out hotspot-comp:

cd ..
hg clone http://hg.openjdk.java.net/hsx/hotspot-comp/
cd hotspot-comp
sh get-source.sh

Finally, I recommend you use my build script for Shark: place it in the toplevel directoy of hotspot-comp and modify all the env variables to your needs. Most importantly, change LLVM_CONFIG to point to your $LLVM_INSTALL_DIR/bin/llvm-config. Enjoy the Shark!

• Hotspot’s internal oop class hierarchy has been split into two: oops (all objects) and metadata (classes, methods, etc). This caused some major headaches because Shark code was basically assuming everything’s an object, and it was not always clear what actually to use: a Klass* or its Java mirror (basically an instance of java_lang_Class)? Etc etc.
• A bunch of intrinsics for atomic operations (compare-swap, memory barrier, etc) have been remove from LLVM, and in their place now is a direct representation in the IR. Which actually makes it much nicer and easier to use in Shark.
• Several smaller little things, to many and probably to little to list here.

With this, I can now do a full build of OpenJDK/Shark on x86, which I am quite proud of. It’s already successfully running a lot of code, but at the same time I am still hitting some bugs. After I have ironed them out I will propose the changes for inclusion in OpenJDK8 of course.

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

Update: If you’re only interested in the patches themselves, have a look at the patch repository.

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:

Update: If you already voted yesterday, you can vote again (everybody can vote once per day, up to July 8th)!

The major new feature is the support for creating and analysing memory by creating a heapdump and browsing a histogram of objects in memory. Additional features include a kill switch, using which you can terminate a running process (for example if it grossly misbehaves), a new Look and Feel (named Dolphin, made to look similar to Gnome 3′s Adwaita theme), new command line commands to support heap analysis, numerous little UI improvements and bugfixes.

The below screenshot shows the new heap analysis view. It monitors the heap usage of a selected JVM. When you click the big ‘Heap Dump’ button, a heap dump image is created and saved in the MongoDB, it shows up in the list below (you can take and analyze several heapdumps per VM.. they will be listed with the timestamp of their creation). Clicking on the heap dump in that list brings up a histogram view that lists all allocated objects, the number of their instances and the total size of their allocation. This list can be sorted by clicking on the respective table headers. (We are planning several more heap analysis features like searching specific objects and following their paths to GC roots, showing incoming and outgoing references, etc etc, but those will show up in the next release, in about 4 weeks from now.)

This was a fairly important release for us, it was our first milestone release, ready just in time for the Red Hat Summit (Deepak will present Thermostat there). Infact, it is the second milestone, milestone 0 was earlier this year when Jon and Omair showed Thermostat at FOSDEM. We took at lot of care and time to make Thermostat solid and useful, and while it’s not overflowing with features yet, we prepared the ground for a lot of greatness. Eventually, Thermostat will support monitoring remote VMs and whole clusters of VMs, and allow drilling down into problem areas and perform deep and fine grained analysis, utilizing information from the JVM itself as well as from the kernel, the operating system and even from the application server.

Please read the release announcement for more details about this new shiny release of Thermostat!

The above pictures were made in April 1999. A friend of mine made this picture during a short trip to the Baltic Sea. This was just days before my life would change forever. It was a very happy time. A few days later I would meet Madeleine for the first time. Had I known what sort of adventure I was heading into… I would do all of it again She turned my life upside down, a few months later I would move in with her in Freiburg, say goodbye to many of my old friends for the last time (many of them I never met again), and it’s been my best decision ever.