Hotspot Zero & OpenJDK8 & DaVinci

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 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
cd hotspot-comp-zero
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.

About Roman Kennke
JVM Hacker, Principal Software Engineer at Red Hat's OpenJDK team, Shenandoah GC project lead, Java Champion

8 Responses to Hotspot Zero & OpenJDK8 & DaVinci

  1. I was going to take a quick look at the necessary changes to get Zero working again (without mlvm), but they don’t seem to be visible from the web UI. It just looks like a straight clone of the OpenJDK8 repositories and using hg pull suggests the same. Where are the changesets?

  2. Hi Roman,

    I’m a noob when it comes to OpenJDK8/MLVM, MQ, etc. so forgive me if this is obvious. Like Andrew, when I clone hotspot-comp-zero I can find no patch directories (.hg doesn’t exist in hotspot or jdk). The additional patch repository you’ve provided contains the patches for hotspot, but I can’t find the JDK patches.


  3. Roman Kennke says:

    Andrew, Robert: I just realized that the patches repository is not cloned automatically by the script. This means that after getting all the sources you need to:

    cd hotspot/.hg
    hg clone
    cd ../..

    Also, you are right, the jdk patches are missing, I will add them ASAP.

  4. Volker Simonis says:

    Dilbert, have you unzipped the debug info files (i.e. libjvm.diz)?
    You have to manually do this, before you can debug with debugging symbols

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: