Hotspot Runtime Overview / VM Lifecycle

openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html

Very good resource to learn how JVM works. Maybe even better than my book. And I am afraid both this web page and the book were from the same writer(s).

• There are several HotSpot VM launchers in the Java Standard Edition, the general purpose launcher typically used is the java command on Unix and on Windows java and javaw commands.
• java
• javaw
• javaws
• appletviewer
• The launcher operations pertaining to VM startup are:
• Parse the command line options, 
• some of the command line options are consumed by the launcher itself, 
• for example -client or -server is used to determine and load the appropriate VM library, 
• others are passed to the VM using JavaVMInitArgs.
• Establish the heap sizes and the compiler type (client or server) if these options are not explicitly specified on the command line.
• Establishes the environment variables such as LD_LIBRARY_PATH and CLASSPATH.
• If the java Main-Class is not specified on the command line it fetches the Main-Class name from the JAR's manifest.
• Creates the VM using JNI_CreateJavaVM in a newly created thread (non primordial thread). 
• Note: creating the VM in the primordial thread greatly reduces the ability to customize the VM, for example the stack size on Windows, and many other limitations
• Once the VM is created and initialized, the Main-Class is loaded, and the launcher gets the main method's attributes from the Main-Class.
• The java main method is then invoked in the VM using CallStaticVoidMethod, using the marshalled arguments from the command line.
• Once the java main method completes, its very important to check and clear any pending exceptions that may have occurred and also pass back the exit status, the exception is cleared by calling ExceptionOccurred, the return value of this method is 0 if successful, any other value otherwise, this value is passed back to the calling process.
• Maybe I need to dig a little bit into this part, which is not very intuitive to me so far.
• The main thread is detached using DetachCurrentThread, by doing so we decrement the thread count so the DestroyJavaVM can be called safely, also to ensure that the thread is not performing operations in the vm and that there are no active java frames on its stack.