The OpenJDK library wants to track and run the shutdown hooks itself
rather than let the VM do it, so we need to tell it when we're
exiting.
Also, in machine.cpp we need to use only the modifiers specified in
the InnerClasses attribute for inner classes rather than OR them with
the flags given at the top level of the class file.
This fixes a couple of tests in the Scala test suite
(run/reflection-modulemirror-toplevel-badpath.scala and
run/reflection-constructormirror-nested-good.scala).
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
In order to calculate the initial stack map of GC roots for an
exception handler, we do a logical "and" of maps across all the
instructions contained in the try block for that handler. This is
complicated by the presence of jsr/ret instructions, though, because
instructions in a subroutine may have multiple maps associated with
them corresponding to all the paths from which execution might flow to
them.
The bug in this case was that we were using an uninitialized map in
our calculation, resulting in a map with no GC roots at all. By the
time the map was initialized, the damage had already been done. The
solution is to treat an uninitialized map as if it has roots at all
positions so that it has no effect on the calculation until it has
been initialized with real data.
My earlier attempt (fa5d76b) missed an important detail, and somehow I
forgot to test the 32-bit OpenJDK build which made that omission
obvious. Here's the fix.
Java requires that NaNs be converted to zero and that numbers at or
beyond the limits of integer representation be clamped to the largest
or smallest value that can be represented, respectively.
I get this error when compiling with "make openjdk=...." on both x86_64 and
arm:
compiling test classes
test/Arrays.java:90: error: reference to equals is ambiguous, both method
equals(float[],float[]) in Arrays and method equals(Object[],Object[]) in
Arrays match
expect(java.util.Arrays.equals(null, null));
test/Arrays.java:95: error: reference to hashCode is ambiguous, both method
hashCode(double[]) in Arrays and method hashCode(Object[]) in Arrays match
java.util.Arrays.hashCode(null);
The attached patch fixes this.
When we skip a single-precision register to ensure a double-precision
load is aligned, we need to remember that in case we see another
single-precision argument later on, which we must backfill into that
register we skipped according to the ABI.
We were assuming the array element size was always the native word
size, which is not correct in general for primitive arrays, and this
led to wasted space at best and memory corruption at worst.
