As documented at
https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html,
the ARM64 iOS ABI differs from the generic ABI in a few important
ways. Specifically, arguments passed via the stack are aligned
according to their natural alignment instead of 8 bytes. The VM's
dynamic call code was aligning each argument to 8 bytes, so native JNI
code couldn't find them in their expected places.
Also, we weren't setting the "os.arch" system property on ARM64, so I
fixed that too.
This method ends up defering to JVM_GetClassDeclaredMethods, which
creates an array of java.lang.reflect.Method instances and then
calling getName on each one through the java.lang.reflect.Member
interface. However, Method is a "bootstrap" class, meaning the VM has
built-in knowledge of it and includes a tentative version built-in but
must load the real version from the classpath at runtime before
invoking methods on it. Normally this happens naturally when Method
instances are created in Java code, but here we're creating them in
the VM instead, which doesn't automatically cause the real class to be
loaded. So we must do so explicitly.
80ce92a introduced a regression which caused the Cygwin build to fail,
since it tried to set platform=$(build-platform) when calling make
recursively, and platform=cygwin is rejected by the makefile.
Instead, we need to use $(bootimage-platform), which normalizes
"cygwin" and "mingw32" to "windows".
On ARM64, conditional branches to immediate offsets can span no more
than 2^19 instructions. In the case of the stack overflow check,
which wants to do a conditional branch from every non-leaf method to a
handler, this can be a problem, especially when compiled code grows
large as with a bootimage=true build against the OpenJDK class
library. Therefore, we use an unconditional branch to reach the
handler on this platform.
When we initialize the vtables for bootstrap Java classes such as
java.lang.NullPointerException (i.e. classes which the VM has built-in
knowledge of), we assign the superclass's vtable to any class which
has no declared virtual methods of its own. However, that vtable will
be null if we haven't initialized the superclass yet. Therefore, we
must order this process such that no class is initialized until after
all its superclasses.
When we intercept a method (i.e. when the VM wants to run its own code
instead of whatever the classpath provides for that method), we make a
clone of the original method so we can later call it from the
intercepting code if appropriate. We also set the ACC_NATIVE flag on
the original method to ensure that our intercepting code is always
used in preference to the classpath version. However, we need to set
that flag *after* we make the clone, or else the clone will also have
the ACC_NATIVE flag set, which is not what we want.
We never noticed this before because classpath versions of all the
methods we intercept as of Java 7 are either native or are never
called from their VM-specified replacements. However, some of those
native methods are non-native in later versions of Java, so the bug
has become apparent.
Also, replace some preprocessor conditionals with C++ conditionals and
add some todo comments and sample code for future work towards better
ABI compatibility in the JIT compiled code.
This fixes a problem with atomically updating JIT-compiled static
calls to AOT-compiled code. It turns out there was also a problem
with the 32-bit ARM code as well, but we never hit it because it is
extremely unlikely that a code address can be loaded with a single
immediate load instruction on 32-bit ARM since it can only handle
numbers with 8 significant bits. I've fixed that as well.
