Method.invoke must throw an IllegalArgumentException if it receives
the wrong number or types of arguments, and since this isn't done by
the OpenJDK class library, we must do it in the VM.
This library is placed in the xawt subdirectory of jre/lib/$arch on
POSIX systems, so it isn't found automatically when third-party
libraries which depend on it are loaded. The simplest way to ensure
that it's found seems to be to just load it when the VM starts up.
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.
Hi,
I did some more tests with my x86 QNX Avian port and found one major problem
in Avian VM while trying to run Apache Ivy. The problem manifests as
follows:
1. MySystem::Thread X is created, during its creation pthread mutex and
conditional variable are initialized
2. Program runs for some time
3. MySystem Thread X is disposed, it's memory is freed (during garbage
collection I guess)
4. Program runs for some time
5. MySystem::Thread Y is created in exactly the same memory address as
MySystem::Thread X disposed in step 3 (I suppose that's due to the way
memory allocator works in Avian)
6. During MySystem::Thread Y creation pthread mutex and conditional variable
initialization fail silently with EBUSY. QNX documentation says it means
"The given mutex was previously initialized and hasn't been destroyed."
which is correct, because it's exactly in the same memory address as mutex
and conditional variable of MySystem::Thread X and they haven't been
destroyed during MySystem::Thread X disposal
Fortunately solution for this is easy, see the attached patch. Now Apache
Ivy works without any problems.
Regards,
Stanisław Szymczyk
OpenJDK.getDeclaringClass is called from JVM_GetDeclaringClass, so we
need to tell ProGuard to preserve it along with the other method we
had already included.
Some OSes (notably, Windows CE) restrict the size of the call stack
such that recursive compilation of branch instructions can lead to
stack overflow in methods with large numbers of such instructions. In
fact, a worst-case method could even lead to overflow when the stack
size limit is relatively generous.
The solution is to convert this recursion into iteration with an
explicit stack to maintain state about alternate paths through each
branch.
