The VM should only assume it should/will crash if it triggers an
e.g. EXCEPTION_ACCESS_VIOLATION itself. In other words, if some
non-VM code triggers such an event, the VM should let that code handle
it as appropriate. Avian already does this properly, but it also
generates crash dumps for each event encountered if avian.crash.dir is
set, regardless if whether the VM triggered it or not. This can be a
problem if such events are generated frequently -- a full memory dump
takes a long time to write and a lot of disk space.
Ideally, we'd have some reliable way to determine whether the faulting
instruction pointer belongs to the VM or not, but the closest thing I
could come up with was to compare the module that owns the address
with the module representing the main executable. This can lead to
both false positives (e.g. application code in the main executable
which is not part of the VM) and false negatives (e.g. when the VM is
loaded from a library instead of the main executable), but it's still
an improvement over the status quo.
Even better would be to ensure that the VM's exception handler is the
very last one to run, so that we know for sure that the error is
unrecoverable and thus it is appropriate to do a full memory dump.
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.
