JVM startup process

1. Creating a JVM load environment and configuration

2. Loading JVM.dll

3. Initialize JVM.dll and hang bounds to jnienv (JNI call interface) instance

4. Call the JNIEnv instance to mount and process the class.

A The JVM loads the environment and the JVM provides the dynamic connection file for the operating system.

Since it's a file, it's just a matter of loading the path, how does Java find the path?

When you call Java test, the operating system will be under path in your Java.exe program, Java.exe the following procedure to determine the path of the JVM and the associated parameter configuration. The following analysis of Windows-based implementations:

1, first find the JRE path, Java is through the Getapplicationhome API to obtain the current Java.exe absolute path, C:\j2sdk1.4.2_09\bin\Java.exe, then it will intercept the absolute path to c \ J2sdk1.4.2_09\, determine if the C:\j2sdk1.4.2_09\bin\Java.dll file exists,

If it exists, use c:\j2sdk1.4.2_09\ as the JRE path,

If it does not exist then determine if c:\j2sdk1.4.2_09\jre\bin\Java.dll exists, if this c:\j2sdk1.4.2_09\jre is present as the JRE path. If there is no call getpublicjrehome Hkey_local_machine\software\javasoft\java Runtime environment\ "Current JRE version number" \ The path to the javahome is the JRE path. (You can check if the path on the CLASSPATH and HKEY_LOCAL_MACHINE is correct when the JVM fails to start)

2. Then mount the jvm.cfg file JRE path +\lib+\arch (CPU architecture) +\jvm.cfg, the ARCH (CPU architecture) is judged by Java_ MD.C in the Getarch function, the function in the Windows platform only two cases: WIN64 ' ia64 ', the other case is ' i386 '. Take my example: C:\j2sdk1.4.2_09\jre\lib\i386\JVM.cfg. The main contents are as follows:

1. -client known
2. -server known
3. -hotspot aliased_to-client
4. -classic WARN
5. -native ERROR
6. -green ERROR

There are JVM.dll files in Jre\bin\server and jre\bin\client in our JDK directory, and Java is managing these different versions of JVM.dll through JVM.CFG configuration files. Through the file we can define the current JDK support those JVMs, the previous part (client) is the JVM name, followed by the parameters, known indicates that the JVM exists, aliased_to to the other JVM to take an alias, warn that does not exist when looking for a JVM substitution, The error indicates that no throw exception exists.

In running Java XXX Yes, Java.exe will check the current JVM type through Checkjvmtype, Java can specify the specific JVM type by two parameters, one is specified by the JVM name in the Jvm.cfg file, the second method is directly specified, and the method they execute is " Java-j "," java-xxaltjvm= "or" java-j-xxaltjvm= ". If the first parameter is passed, the Checkjvmtype function takes the name of the JVM after the argument '-j ', and then looks for the '-' directly returning the value before removing the JVM name from the known JVM configuration parameter, and the second method returns directly to the-XXALTJVM The JVM type name after = "or"-j-xxaltjvm= ", if either of the above methods is not specified when running Java, Checkjvmtype takes the name of the JVM from the first configuration in the configuration file, removing the '-' from the front of the name to return the value. This return value of the Checkjvmtype function combines the JRE path into the absolute path of JVM.dll in the following function. If not specified, this will use the first defined JVM in Jvm.cfg. The set _java_launcher_debug=1 can be tested on the console.

Finally, the path to JVM.dll is obtained, and the JRE path +\BIN+\JVM type string +\jvm.dll is the file path of the JVM, but if the path is specified with the-xxaltjvm= parameter when calling the Java program, it is used directly path+\ JVM.dll file as a JVM.dll file path.

Two: Load JVM.dll

The path to the JVM has been found through the first step, and Java is loaded into the JVM.dll file by LOADJAVAVM. Loading a job is a simple call to a Windows API function:

LoadLibrary load JVM.dll dynamic Connection library. Then JNI_CREATEJAVAVM and jni_ the exported functions in the JVM.dll Getdefaultjavavminitargs is attached to the CREATEJAVAVM and Getdefaultjavavminitargs function pointer variables of the invocationfunctions variable. The loading work of the JVM.dll is declared complete.

Three: Initialize JVM, get local calling interface

This makes it possible to invoke the JVM's functions in Java. Call INVOCATIONFUNCTIONS->CREATEJAVAVM, the Jni_createjavavm method in the JVM, to get an instance of the JNIENV structure.

Four: Run the Java program.

Java programs have two ways, one is a jar package, and the other is a. Class:

When running Jar,java-jar Xxx.jar run, Java.exe calls the Getmainclassname function, which first obtains the jnienv instance, Then call the Java class Java.util.jar.JarFileJNIEnv method Getmanifest () and take the value of GetAttributes ("Main-class") from the returned Manifest object, which is the file in the jar package: Meta-inf/manifest. The main class of the Main-class specified by MF is the main class of the run. the LoadClass method in JAVA.C is then called to load the main class (using the Findclass of the JNIEnv instance). Then call the Getstaticmethodid method of the JNIEnv instance to find the "public static void Main (string[] args)" Method in the loaded class main class and determine if the method is public. Then call the Callstaticvoidmethod method of the JNIEnv instance to invoke the Java class's main method.

JVM startup process