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.
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.
Although the JNI reference documentation does not mention it,
FindClass should initialize the class before it returns it. That's
what HotSpot does, and that's what we have to do too.
In particular, OpenJDK's
Java_java_net_Inet6AddressImpl_lookupAllHostAddr relies on
Inet6Address's static initializer being run when it is resolved using
FindClass, or else it will crash.
We must be in the Active state, not the Exclusive state when calling
this method since it may execute arbitrary Java code. This fixes an
assertion failure in makeNew.
If sun.java.command or sun.java.launcher are set, then the VM is being
loaded from e.g. libjvm.so, not as a stand-alone executable. This
commit allows libjvm.dylib to be used with OpenJDK's java command on OS
X.
This is necessary to ensure that new threads do not start while we're
shutting down (except for the ones that we start to run the shutdown
hooks), and that the shutdown hook threads can be safely started (it
is not safe to start threads from e.g. an idle state, and an assertion
will fail if we do).
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
This is necessary to avoid name conflicts on various platforms. For
example, iOS has its own util.h, and Windows has a process.h. By
including our version as e.g. "avian/util.h", we avoid confusion with
the system version.
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.
If we increment the value while we're still in IdleState, another
thread may try to GC before we are able to enter ActiveState, which
will lead to an assertion failure when the footprint function is
called.
Recent versions of IcedTea will not run unless libjvm.so exports this
symbol. The quick fix is to provide a stub which just always returns
-1 to indicate an error. I'll leave a proper implementation for when
we need to support an app that actually uses this function.
My earlier commit to allow detaching the main thread (1f1c3c4) seems
to have caused subtle stability problems
(e.g. https://groups.google.com/group/avian/msg/d2c797c0dcf925c3), so
for now we'll just ignore that operation, which leaks a bit of memory
but should be harmless otherwise.
When I originally implemented DetachCurrentThread, I assumed it didn't
make sense for the main thread to detach itself from the VM, and I was
concerned that allowing it might cause problems for any other threads
still attached. However, detaching the main thread is allowed by the
JNI spec as of Java 2, and OpenJDK's java command does this just
before calling DestroyJavaVM. Therefore, this commit ensures that the
VM doesn't abort if the main thread is detached.
