OpenJDK 7 support

[dz333]

From @gharrma on May 24, 2018 16:50

This issue subsumes #3

Support for the full OpenJDK is close, but not finished. PolyLLVM can compile a large portion of the JDK down the LLVM IR (the 1000+ files required for a Hello World program); the remaining JDK files might also compile, but this has not been tried yet. The resulting LLVM IR compiles and links successfully with a Hello World program. We link directly with the native code provided by a standard JDK 7 installation.

However, running the Hello World program does not work, because the JDK relies heavily on JVM-provided functionality (think: reflection, calling Java methods from native code, starting new threads, and much more). Implementing this functionality for PolyLLVM is a work in progress. Fortunately, JVM-functionality is well specified in terms of three interfaces.

(1) Java Native Interface (JNI). JNI allows native code (C/C++) to interact with Java object and the JVM. It includes methods like CallObjectMethod, IsInstanceOf, and GetIntArrayElements. This is a public and stable API, and it's used directly by native code in the JDK. All methods take only opaque pointers as arguments, but of course their implementation requires implementation-specific details regarding object layout, dispatch vector layout, etc. Thus we must implement most of these methods, and link them into each executable. Much of this has already been done (especially Java field and array element access), but there's still more to do. All methods are defined in runtime/native/jni.cpp, and unimplemented methods throw errors at runtime.

(2) JVM interface (see here for a discussion). This is similar and complementary to the JNI interface, though I believe it's specific to OpenJDK and HotSpot. Nonetheless, we must implement and link the methods in this interface because the JDK uses it heavily within native code. This includes methods like JVM_FillInStackTrace, JVM_ArrayCopy, JVM_MonitorNotify, JVM_StartThread, JVM_Socket, JVM_AllocateNewObject, JVM_GetClassDeclaredFields, and more. This interface is largely unimplemented so far. All methods are defined in runtime/native/jvm.cpp. I recommend looking at the jvm.h file in HotSpot to get an idea of what each method is supposed to do.

(3) java.misc.Unsafe. This interface is a bit different than the others. On the surface it is just a Java class---except the JVM treats each of its method as a marker for a compiler intrinsic! For example, this interface is used to give Java code access to compare-and-swap operations. This interface is largely unimplemented so far. All methods are defined in runtime/native/unsafe.cpp.

To give a concrete idea of what happens when trying to run a program while JVM-functionality is unfinished, here's the output of running Hello World as of May 24, 2018.

- - - - - - - - - - - - - - - - - - - - - - - - - - -
The following JVM method is currently unimplemented:
  JVM_DoPrivileged
It is defined in native/jvm.cpp.
Aborting for now.
- - - - - - - - - - - - - - - - - - - - - - - - - - -

The method JVM_DoPrivileged is called by JDK code in order to request that the VM perform some privileged action on their behalf. It is called in a Hello World program because the static initializers for java.nio.charset.Charset include the line

AccessController.doPrivileged(new GetPropertyAction("file.encoding"));

and Charset is required for printing to System.out.

Copied from original issue: gharrma/polyllvm#54

[dz333]

Lots of OpenJDK7 support has since been enabled.

In fact, enough has been enabled that all of the tests in tests/isolated currently pass except for HashTableTest.java.

This fails because the AtomicInteger classes end up using advanced reflection (Class.getDeclaredFields) which is currently unimplemented.

For runtime support that has yet to be completed or started see the following issues:

#27, #26, #25, #24 and #23

There are a large number of other interface methods that remain unimplemented simply because they were not necessary to getting the OpenJDK initialization code to run or any of our unit tests. Many of these are relatively similar to already implemented functions (e.g. there are 3 different getByte function in unsafe.cpp, only 2 have been implemented so far). These should be straightforward to implement but are numerous.