If the JNI call DestroyJavaVM is called from a native method, bad things happen. If it is called from the the 'main' thread, with Java frames still on the stack, the VM crashes somewhere in Thread::~Thread() when trying to free PerfData memory. In debug mode, it hits an assert about handle marks first. If DestroyJavaVM is called from multiple threads, it causes a deadlock as each thread waits for all others to finish in Threads::destroy_vm(). This can come about if a created thread calls DestroyJavaVM explicitly and the main thread falls off the end of main() normally (where the launcher will call DestroyJavaVM).

According to the JNI spec:
---
jint DestroyJavaVM(JavaVM *vm);

Unloads a Java VM and reclaims its resources. Only the main thread can unload the VM. The main thread must be the only remaining user thread when it calls DestroyJavaVM().
---

So the second case definitely violates the spec, and the first one might as well (depending on the definition of "main thread"), but either way we should probably handle these erroneous cases more gracefully by returning a JNI_ERR value to the caller.

The attached code builds on Solaris and demonstrates both cases (run 'gnumake test').

In addition, the comment in thread.cpp above Threads::destroy_vm() should be updated, as it is out of date and refers to multiple entry points to this function, where it appears that only JNI_DestroyJavaVM calls this method (System.exit() goes to JVM_Halt() while serious errors call vm_exit() or vm_abort() directly).