If AVIAN_AOT_ONLY is defined and the VM is asked to compile a method
anyway, we should abort immediately rather than let it crash later
(e.g. due to an access violation on a non-jailbroken iPhone). This
makes debugging such issues a bit easier since the failure will come
earlier and with a more obvious cause.
If a BuiltinElement is never used (i.e. we never try to load anything
from it), its init method will never be called, and thus its backing
library will never be loaded. In that case, we should not try to call
library->disposeAll() in the destructor.
Lots has changed since we forked Android's libcore, so merging the
latest upstream code has required extensive changes to the
Avian/Android port.
One big change is that we now use Avian's versions of
java.lang.Object, java.lang.Class, java.lang.ClassLoader, some
java.lang.reflect.* classes, etc. instead of the Android versions.
The main reason is that the Android versions have become very
Dex/Dalvik-specific, and since Avian is based on Java class files, not
dex archives, that code doesn't make sense here. This has the side
benefit that we can share more native code with classpath-avian.cpp
and reduce the amount of Java/C++ code duplication.
This function allows you to call native code such that any
SIGSEGV/SIGBUS/SIGFPE/EXC_ACCESS_VIOLATION/etc. raised by that code is
transformed into a Java exception and thrown by tryNative. Note that
this effectively results in a longjmp out of whatever function raised
the exception, so any C++ destructors or other cleanup code will not
be run.
Recent versions of jni.h such as the one provided by Debian Jessie's
OpenJDK define UNUSED in a way that conflicts with our definition and
usage, so we need to explicitly undefine it before redefining it to
avoid compiler noise.
It looks like the UNIXProcess class has added posix_spawn support,
which is enabled by default unless overriden by the
jdk.lang.Process.launchMechanism system property. For some reason I
haven't bothered to investigate, posix_spawn fails on MacOS, so this
patch sets the aforementioned property to "fork" to get the old,
working behavior.
This particular problem was introduced in the recent "compiler types" refactor.
It's unclear why it wasn't encountered before now.
Note that the full, unproguarded bootimage build is still blocked by #305
