There are two problems:
* The x86 JIT compiler requires detectFeatures, defined in the x86 assembly.
Thus it can't (currently) be built on non-x86 platforms.
For the purposes of fixing test/ci.sh, it suffices to pretend
codegen-targets=all means codegen-targets=native when on arm.
* Qemu can introduce some extra latency which was regularly screwing up the LinkedBlockingQueueTest.
Solution: increase the timeout to 1/10th seconds.
I also changed TreeMap to implement the "SortedMap" interface, like it should. Unfortanetly not all the code to implement the interface was there. Where it was simple I implemented the additional functions, in the case of headMap, tailMap, subMap we are currently just throwing an UnsupportedOperationException.
This was a bug, wherein upon throwing an exception, we would try to
allocate memory for the message - all while holding a critical
reference to the jbyteArray representing the exception string. This
caused an expect to fail in allocate3.
The only Linux/ARM machine I have access to does not support ARMv7. I
don't know how common that is in general, but this seems like the safe
default. You can always override it on the command line.
I've also broken the test target into build-test and run-test
subtargets, which can be useful when you're building on a shared
filesystem and running the tests on another machine (without using the
remote-test-host option). If there's clock skew, the other machine
might try to rebuild stuff unecessarily. Using run-test avoids
that.
This ensures that all tests pass when Avian is built with an
openjdk=$path option such that $path points to either OpenJDK 7 or 8.
Note that I have not yet tried using the openjdk-src option with
OpenJDK 8. I'll work on that next.
The Misc test was failing when run as "make input=Misc run" since
test-flags did not include $(build)/extra-dir in the class library,
leading the ClassLoader.getResources test to fail.
Also, the UnknownHostException test was not reliable -- some ISPs
(mine included) return DNS matches for bogus hostnames, defaulting to
the IP address of a webserver intended to help users with name
resolution problems. That's dumb, I know, but I'm guessing I'm not
the only person with a dumb ISP, and it seems better to just remove
the test than make people think Avian is broken when it's really just
their DNS server that's broken.
Let's not say 'lastest'. That would only confuse non-native speakears
such as yours truly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
617bd85 broke the Android build by creating an unresolvable
order-of-operations bug in classpath-android.cpp's
MyClasspath::preBoot method.
The problem is that, while JNIEnv::FindClass is supposed to initialize
the class that it finds, this causes JniConstants::init to indirectly
invoke native methods which are not registered until JNI_OnLoad is
called (which happens after JniConstants::init is called). However,
if we call JNI_OnLoad first, that causes methods to be invoked which
rely on JniConstants::init having already been run.
I haven't checked to see how Dalvik handles this, but I don't see any
way around the problem besides disabling initialization by
JNIEnv::FindClass until the preBoot phase is complete. Moreover, it's
dangerous to allow Java code to be invoked so early anyway, since the
VM is not yet fully initialized.
For some reason, running Avian under the SVN version of Valgrind
caused mmap to fail, which caused tryAllocateExecutable to return a
null pointer, which led to a non-obvious crash later on. Adding an
expect to check the result immediately will at least make it obvious
what went wrong.
bb86500 was a step in the right direction, but there was a bug that
caused Type_pad fields to be inserted between every other field in for
a derived class when type-maps.cpp was generated, and this led to
miscompilation of e.g. Android's
java.lang.reflect.Constructor.getModifiers.
These flags are only needed to ensure that libjvm.so can be used as a
drop-in replacement for OpenJDK's VM, and that only makes sense for
openjdk builds (without the openjdk-src option). It didn't hurt
anything to define them unconditionally, but it was misleading.
We should define EXPORT to be __declspec(dllexport) on Windows
regardless of architecture, not just non-x86_64 arches. This fixes
errors to to embedded JAVA_HOME files not being found in openjdk-src
builds, e.g. lib/currency.data.
