This addresses a recent regression where different versions of
MinGW(-w64) had different opinions about whether to use e.g. %I64d or
%lld to print 64-bit integers on 32-bit platforms.
MinGW defines __STRICT_ANSI__ when -std=c++0x is specified, which we
have to override in order to get e.g. strdup. Also, we need to
specify -D_WIN32_WINNT=0x0500 to get post-Windows-2000 functions like
GetModuleHandleEx. Finally, it seems that GCC 4.8.1 wants us to use
%I64d instead of %lld on Windows.
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
So there I was, planning to just fix one little bug: Thread.holdsLock
and Thread.yield were missing for the Android class library. Easy
enough, right? So, I added a test, got it passing, and figured I'd go
ahead and run ci.sh with all three class libraries. Big mistake.
Here's the stuff I found:
* minor inconsistency in README.md about OpenSSL version
* untested, broken Class.getEnclosingMethod (reported by Josh)
* JNI test failed for tails=true Android build
* Runtime.nativeExit missing for Android build
* obsolete assertion in CallEvent broke tails=true Android build
* obsolete superclass field offset padding broke bootimage=true Android build
* runtime annotation parsing broke bootimage=true Android build
(because we couldn't modify Addendum.annotationTable for classes in
the heap image)
* ci.sh tried building with both android=... and openjdk=..., which
the makefile rightfully balked at
Sorry this is all in a single commit; I didn't expect so many
unrelated issues, and I'm too lazy to break them apart.
The VM should only assume it should/will crash if it triggers an
e.g. EXCEPTION_ACCESS_VIOLATION itself. In other words, if some
non-VM code triggers such an event, the VM should let that code handle
it as appropriate. Avian already does this properly, but it also
generates crash dumps for each event encountered if avian.crash.dir is
set, regardless if whether the VM triggered it or not. This can be a
problem if such events are generated frequently -- a full memory dump
takes a long time to write and a lot of disk space.
Ideally, we'd have some reliable way to determine whether the faulting
instruction pointer belongs to the VM or not, but the closest thing I
could come up with was to compare the module that owns the address
with the module representing the main executable. This can lead to
both false positives (e.g. application code in the main executable
which is not part of the VM) and false negatives (e.g. when the VM is
loaded from a library instead of the main executable), but it's still
an improvement over the status quo.
Even better would be to ensure that the VM's exception handler is the
very last one to run, so that we know for sure that the error is
unrecoverable and thus it is appropriate to do a full memory dump.
If an JNI_OnLoad implementation calls FindClass when using the OpenJDK
class library, the calling method on the Java stack will be
ClassLoader.loadLibrary. However, we must use the class loader of the
class attempting to load the library in this case, not the system
classloader.
Therefore, we now maintain a stack such that the latest class to load
a library in the current thread is at the top, and we use that class
whenever FindClass is called by ClassLoader.loadLibrary (via
JNI_OnLoad).
Note that this patch does not attempt to address the same problem for
the Avian or Android class libraries, but the same strategy should
work for them as well.
There's no need to enter IdleState (and incur synchronization
overhead) unless another thread is waiting to enter ExclusiveState.
This change improves the performance of the MemoryRamp test by a
factor of about 100.
