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.
I must have done a search-and-replace from 4 to TargetBytesPerWord
earlier, but in this case it should have been the instruction size
(4), not the word size.
