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.
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.
The -flto flag slows down linking dramatically without providing a
noticeable improvement in speed or size. Rather than take the
build-time hit every time we rebuild, let's only do it when it's
explicitly requested.
c2bfba9 introduced a regression such that building against a non-Avian
class library failed due to avian.Cell not being added to the library.
Since avian.Continuations depends on that class, the build broke.
I've been told by knowledgeable people that it is impossible to
implement composable continuations (AKA delimited continuations AKA
shift/reset) in terms of call-with-current-continuation. Since I
don't yet understand why that is, I figured it would help my
understanding to attempt it and see how it fails.
armv7 and later provide weaker cache coherency models than armv6 and
earlier, so we cannot just implement memory barriers as no-ops. This
patch uses the DMB instruction (or the equivalent OS-provided barrier
function) to implement barriers. This should fix concurrency issues
on newer chips such as the Apple A6 and A7.
If you still need to support ARMv6 devices, you should pass
"armv6=true" to make when building Avian. Ideally, the VM would
detect what kind of CPU it was executing on at runtime and direct the
JIT compiler accordingly, but I don't know how to do that on ARM.
Patches are welcome, though!
It looks like the iOS 7 SDK doesn't have GCC anymore, so we need to
use clang instead. Also, thread_act.h and thread_status.h have moved,
so I updated arm.h accordingly. That might break the build for older
SDKs, but I don't have one available at the moment. If it does break,
I'll fix it.
The intent of this target is to run our test suite against the installed jre.
This should help prevent our VM from diverging in implementation from the jdk.
The remainder of this commit fixes the problems that this exposes.
Earlier, if the annotations were already up-to-date (but
Annotations.class not), the compilation would fail.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This adds an extra class path element to the VM running the unit tests,
writes files with identical file names into both directories and then
verifies that SystemClassLoader#getResources can find them.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This mainly involved reworking the makefile to avoid conflating
Darwin/ARM builds with iOS, since we may also want to build for the
iOS Simulator, which is i386.
Note that I was only able to test this on the Simulator, since I don't
have a real iOS device to test with. Sorry if I broke something; if
so, please fix it :)
There were two issues: the linux->darwin cross compiler is more stringent
about unused variables, and the makefile specified flags for building ON
darwin that were actually applicable whenever we are building FOR darwin.
Per https://github.com/ReadyTalk/avian/issues/53, Avian should build
against a standard AOSP checkout, which means we should look for
subprojects in the directories the repo utility would place them.
Setting this property (e.g. -Davian.trace.port=5555) will cause the VM
to start an extra daemon thread which listens on the specified TCP
port for incoming connections and dumps stack traces for all running
threads to that socket. You can retrieve that dump using e.g. netcat:
nc localhost 5555
With corresponding changes to libcore, all the tests are passing
except Datagrams, which fails with a NPE in
NetworkInterface.getNetworkInterfacesList due to OS X not having
/sys/class/net. Porting that class to OS X looks like a non-trivial
task.
This fixes the iOS build, where the wrong version of util.h was being
used. The change to use -idirafter happened way back in 2007, and I
can't remember what its intention was. We'll have to watch for
regressions on other platforms.
It now builds and links, but fails at runtime because
register_libcore_icu_ICU can't find the file it wants. We'll probably need to replace register_libcore_icu_ICU with a better-behaved version.
Stuff compiles, but linking breaks spectacularly. Next step is to
figure out how to build the dependencies without checking out and
building the entire Android platform.
To execute tests on a remote host (for instance, because you're cross-compiling),
simply do:
make remote-test=true remote-test-host=<host_to_test_on> test
You can set several variables to control the functionality of remote-test.
See them below, along with their default values:
remote-test-host = localhost # host to ssh to
remote-test-port = 22
remote-test-user = ${USER} # user to execute tests as
remote-test-dir = /tmp/avian-test-${USER} # dir to rsync build output to
The primary motivation behind this is to allow all the different Assemblers
to be built at once, on a single machine. This should dramatically reduce
the time required to make sure that a particular change doesn't break
the build for one of the not-so-common architectures (arm, powerpc)
Simply pass "codegen-targets=all" to make to compile all
src/codegen/<arch>/assembler.cpp.
Note that while these architectures are built, they will not be fully-
functional. Certain stuff is assumed to be the same across the entire
build (such as TargetBytesPerWord), but this isn't the case anymore.
