sun.misc.Unsafe broken in Hotspot (and J9)

We went through a great deal of pain trying to get sun.misc.Unsafe to work properly in our VM. We use it extensively for the interpretative backends (JPL and BPL). It turns out that the C2 compiler (server JIT) of Hotspot generates incorrect machine code for sun.misc.Unsafe.putByte in certain conditions. We searched the Hotspot bug database and couldn’t find any entries on this issue yet. Bernd offered to put us in touch with someone from the C2 engineering team if we can reduce the problem enough to post it to the bug database. Right now the issue is reproducible by running a certain test case through our VM. To file a report we have to find out under what conditions exactly C2 fails.

We have observed the same bug on our main platform (Apple’s Hotspot 6.0preview and 5.0 ports), but also on Linux (Sun’s Hotspot 6.0). For the latter 32-bit and 64-bit x86 are affected. IBM’s J9 VM that ships with 5.0 and 6.0earlyaccess does not break, which increases our confidence that our use of sun.misc.Unsafe is correct, and the bug is in C2. On the downside, even J9 seems to break in certain cases (i.e. accessing a large array via sun.misc.Unsafe). To make a long story short, we had to part with the idea of using sun.misc.Unsafe. It works in the Hotspot interpreter and C1, but is pretty slow. Its broken in Hotspot C2, which is the only JIT that is reasonably fast when it comes to sun.misc.Unsafe. Even IBM’s J9 is pretty slow since it probably doesn’t support sun.misc.Unsafe as builtin intrensics.

We have revamped our backend to use xALOAD and GET/PUT/FIELD/STATIC for memory access. This does introduce some extra overhead since null and typechecks are now done redundantly, once by our guard, and then again by the memory access operation.

While rewriting the backend we also stumbled over a gigantic security loophole. By injecting a public version of sun.reflect.MagicAccessorImpl into the classpath before the standard library JDK jars we are able to selectively disable the verifier for certain classes. We don’t think that this works for applets since class loading is controlled more thoroughly in that environment.