Shulou(Shulou.com)06/03 Report--

Today, I will talk to you about the example analysis of JVM.dll loading process and source code, which may not be well understood by many people. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

JVM.dll is a library that contains code and data that can be used by multiple programs simultaneously. For example, in the Windows operating system, Comdlg32DLL performs common functions related to dialog boxes.

Talking about JVM.dll loading process and Source Code Analysis

It is well known that java.exe is the executor of javaclass files, but in fact, the java.exe program is just an execution shell, which loads JVM.dll. This dynamic link library is the actual operation of the java virtual machine. This article explores how java.exe programs find and load JVM.dll dynamic libraries and call it for class file execution processing.

JVM.dll source code

The code for the analysis of this article, "JavaTM2SDK,StandardEdition,v1.4.2fcsCommunitySourceRelease", can be downloaded from the official website of sun. The source code of the main analysis is: j2se\ src\ share\ bin\ java.cj2se\ src\ windows\ bin\ java_md.c

What is java.c?

The source code of 'java program' is called 'java program', which includes the code generated by the JAVA_ARGS macro in the java.exe\ javac.exe\ javadoc.exe,java.c source code in jdk. If the macro is not defined, the compilation file controls the generation of java.exe, otherwise the compilation file controls the generation of other 'java programs'. For example: j2se\ make\ java\ javac\ Makefile (this is the javac compiled file): $(CD).. /.. / sun/javac $(MAKE) $@ RELEASE=$ (RELEASE) FULL_VERSION=$ (FULL_VERSION) j2se\ make\ sun\ javac\ javac\ Makefile (called by the above Makefile file): JAVA_ARGS= "{\"-J-ms8m\ ",\" com.sun.tools.javac.Main\ "}", then the javac.exe program generated by the same java.c code directly calls the java class method: com.sun.tools.javac.Main, which makes it execute as if it were an exe file that runs directly. Java.exe programs that do not define JAVA_ARGS will call the class methods in the passed parameters.

Start with the main entry function of java.c

The previous paragraph in the main () function is the process of reassigning parameter pointers. Then call the function: CreateExecutionEnvironment, which mainly finds the directory of the java runtime environment and the file path of JVM.dll, the virtual machine core dynamic link library. There are different implementation versions of this function depending on the operating system, but the processing logic is generally the same. Let's take a look at the processing of this function on the windows platform (j2se\ src\ windows\ bin\ java_md.c).

The CreateExecutionEnvironment function is mainly divided into three steps: a, finding the jre path. B. Load the virtual dynamic link library (JVM.dll) parameters specified in jvm.cfg. C. Take the path of JVM.dll file.

Achieve:

◆ a, finding the jre path is achieved through the function in java_md.c: GetJREPath.

The function first calls the GetApplicationHome function, and the GetApplicationHome function calls the windowsAPI function GetModuleFileName to get the absolute path of the java.exe program. Take my jdk installation path as an example, as "D:\ java\ j2sdk1.4.2_04\ bin\ java.exe", then remove the file name and take the absolute path as "D:\ java\ j2sdk1.4.2_04\ bin", and then remove the * * level directory. Now the absolute path is: "D:\ java\ j2sdk1.4.2_04". Then the GetJREPath function continues to determine whether the java.dll file synthesized by the path +\ bin\ java.dll group just taken exists. If so, "D:\ java\ j2sdk1.4.2_04" is the JRE path, otherwise, the "D:\ java\ j2sdk1.4.2_04" path +\ jre\ bin\ java.dll file exists, then "D:\ java\ j2sdk1.4.2_04\ jre" is the JRE path. If neither of the above exists, look for it in the registry (see function GetPublicJREHome).

Function: GetPublicJREHome first looks for the key value "current JRE version number" of HKEY_LOCAL_MACHINE\ Software\ JavaSoft\ JavaRuntimeEnvironment\ CurrentVersion, and determines whether "current JRE version number" is used as the version number. If so, the path of HKEY_LOCAL_MACHINE\ Software\ JavaSoft\ JavaRuntimeEnvironment\ "current JRE version number"\ JavaHome is the JRE path.

The JRE path returned by my JDK is "D:\ java\ j2sdk1.4.2_04\ jre".

◆ b, loading jvm.cfg virtual dynamic link library configuration file is realized through the function in java.c: ReadKnownVMs.

This function first combines the absolute path of the jvm.cfg file. The JRE path +\ lib+\ ARCH (CPU framework) +\ jvm.cfgARCH (CPU framework) is judged by the GetArch function in java_md.c. In this function, there are only two cases in the windows platform: WIN64's' ia64','is' i386'. Mine is i386, so the absolute path to the jvm.cfg file is: "D:\ java\ j2sdk1.4.2_04\ jre\ lib\ i386\ jvm.cfg". The contents of the document are as follows:

# # @ (#) jvm.cfg 1.703 plus01pxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # SUNPROPRIETARY/CONFIDENTIAL.Useissubjecttolicenseterms. # ListofJVMsthatcanbeusedasanoptiontojava,javac,etc. # Orderisimportant--irstinthislististhedefaultJVM. # NOTEthatthisboththisfileanditsformatareUNSUPPORTEDand # WILLGOAWAYinafuturerelease. # # YoumayalsoselectaJVMinanarbitrarylocationwiththe # "- XXaltjvm=" option,butthattooisunsupported # andmaynotbeavailableinafuturerelease #-clientKNOWN-serverKNOWN-hotspotALIASED_TO-client- classicWARN-nativeERROR-greenERROR

(if you are careful, we will find that there are JVM.dll files in my JDK directory: "D:\ java\ j2sdk1.4.2_04\ jre\ bin\ client" and "D:\ java\ j2sdk1.4.2_04\ jre\ bin\ server". Java manages these different versions of JVM.dll through the jvm.cfg configuration file. )

The ReadKnownVMs function reads the configuration content from this file into a global variable of the JVM configuration structure. The function first skips comments (lines that start with'#'), and then reads the jvm parameter specified by the line starting with'-', with one jvm information for each behavior. The * * part is the jvm virtual machine name, and the second part is the configuration parameter. For example, line: "- clientKNOWN" then "- client" is the virtual machine name. While "KNOWN" is the configuration type parameter, "KNOWN" indicates the existence of the JVM.dll of the virtual machine, and "ALIASED_TO" is represented as an alias of another JVM.dll, "WARN" means that the JVM.dll of the virtual machine does not exist but will be executed instead of other existing JVM.dll at run time, and "ERROR" also means that the JVM.dll of this type of virtual machine does not exist and the runtime will not find an existing JVM.dll replacement and directly throw an error message.

The judgment of specifying which virtual machine to use when running the java program is determined by the function in java.c: CheckJvmType, which checks whether there is a parameter of the specified jvm in the running parameters of java, and then looks it up in the jvm.cfg data structure read by the ReadKnownVMs function, thus specifying different jvm types (resulting in loading different JVM.dll). There are two ways to specify the jvm type, one according to the jvm name in the jvm.cfg file, and the second is to specify directly, and the methods they execute are "java-J", "java-XXaltjvm=", or "java-J-XXaltjvm=". If the parameter is passed by * *, the CheckJvmType function will take the jvm name after the parameter'- J', and then look among the known jvm configuration parameters for the'- 'before removing the jvm name if the same name is found, and directly return the value; while the second method will directly return the jvm type name after "- XXaltjvm=" or "- JLV XXaltjvm =" If you do not specify either of the above two parameters when running java, CheckJvmType will take the jvm name from the * configuration in the configuration file, remove the'- 'before the name and return this value. This return value of the CheckJvmType function is combined with the jre path to form the absolute path of JVM.dll in the following function.

For example, if you use "java-J-clienttest" when running a java program, ReadKnownVMs will read the parameter "- client" and find out if any of the parameters read by jvm.cfg have the jvm name of "- client". If so, remove the "-" before the jvm name and return "client" directly. If you use the following parameters when running the java program: "java-XXaltjvm=D:\ java\ j2sdk1.4.2_04\ jre\ bin\ clienttest", ReadKnownVMs will directly return "D:\ java\ j2sdk1.4.2_04\ jre\ bin\ client". If you do not take the above parameters, such as "javatest", because the * existing jvm in the jvm.cfg configuration file is "- client", the function ReadKnownVMs will also remove the "-" before the jvm name and return "client". In fact, in all three cases, the jvm dynamic link library "D:\ java\ j2sdk1.4.2_04\ jre\ bin\ client\ JVM.dll" is used to handle the class of test, as shown in the GetJVMPath function below.

◆ c, the path to the JVM.dll file is achieved through the function in java_md.c: GetJVMPath.

From the above two steps we have obtained the JRE path and the type string of jvm. The GetJVMPath function determines whether the jvm type string returned by CheckJvmType contains'\'or'/'. If so, the jvm type string +\ JVM.dll is used as the full path of the JVM, otherwise the JRE path +\ bin+\ jvm type string +\ JVM.dll is used as the full path of the JVM.

Take a look at the example above. In the case of "java-J-clienttest", the JVM.dll path is: JRE path +\ bin+\ jvm type string +\ JVM.dll according to my JDK path: "D:\ java\ j2sdk1.4.2_04\ jre" + "\ bin" + "\ client" + "\ JVM.dll". In the second case, the path "java-XXaltjvm=D:\ java\ j2sdk1.4.2_04\ jre\ bin\ clienttest" is: jvm type string +\ JVM.dll: "D:\ java\ j2sdk1.4.2_04\ jre\ bin\ client" + "\ JVM.dll" the third case "javatest" is: "D:\ java\ j2sdk1.4.2_04\ jre" + "\ bin" + "\ client" + "\ JVM.dll" is the same as in case one. So in all three cases, the calling jvm dynamic link library "D:\ javaj2sdk1.4.2_04\ jre\ bin\ client\ JVM.dll" handles the test class.

Let's further verify: open the cmd console:

Set up java mount debug E:\ work\ java_research > set_JAVA_LAUNCHER_DEBUG=1

Case one E:\ work\ java_research > java-J-clienttest.ScanDirectory----_JAVA_LAUNCHER_DEBUG

After reading the above, do you have any further understanding of the JVM.dll loading process and the sample analysis of the source code? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.