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

How to use java source code to analyze the jvm.dll loading process, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can get something.

Brief introduction

It is well known that java.exe is the executor of java class files, but in fact the java.exe program is just

An executable shell that loads jvm.dll (under windows, the following takes the windows platform as an example

Linux and solaris are actually similar, for: libjvm.so), this dynamic link library is java

Where the actual operation of the virtual machine is handled. This article explores how java.exe programs find and load jvm.dll.

Dynamic library, and call it for class file execution processing.

source code

The source code of the main analysis is:

J2sesrcshareinjava.c

J2sesrcwindowsinjava_md.c

What is java.c?

The source code of java program

The so-called 'java program' includes the java.exejavac.exejavadoc.exe,java.c source in jdk

The generated code is controlled by the JAVA_ARGS macro in the code, and if the macro is not defined, the file controller is compiled.

Java.exe otherwise the compiled file controls the generation of other 'java programs'.

For example:

In j2semakejavajavacMakefile (this is the javac compiled file):

$(CD).. / sun/javac; $(MAKE) $@ RELEASE=$ (RELEASE) FULL_VERSION=$ (FULL_VERSION)

J2semakesunjavacjavacMakefile (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 calls the java class method directly:

Com.sun.tools.javac.Main, which makes it execute as if it were an exe file run 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 looks up the

Directory, and jvm.dll, the virtual machine core dynamic link library file path. Depending on the operating system

There are different implementation versions of this function, but the processing logic is generally the same. Let's take a look at the function on the windows platform.

J2sesrcwindowsinjava_md.c.

The CreateExecutionEnvironment function is mainly divided into three steps:

A. Find 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 windows

The API function GetModuleFileName takes the absolute path of the java.exe program, taking my jdk installation path as an example

Is: "D:javaj2sdk1.4.2_04injava.exe", then remove the file name and take the absolute path as:

"D:javaj2sdk1.4.2_04in", after which the last level of directory will be removed, and now the absolute path is:

"D:javaj2sdk1.4.2_04".

Then the GetJREPath function continues to judge the java.dll synthesized by the path just taken + injava.dll group.

Whether the file exists, and if so, "D:javaj2sdk1.4.2_04" is the JRE path, otherwise it is judged to get

Whether the "D:javaj2sdk1.4.2_04" path + jreinjava.dll file of

"D:javaj2sdk1.4.2_04jre" is the JRE path. If neither of the above cases exists, then from the note

Look for it in the book table (see function GetPublicJREHome).

Function: GetPublicJREHome looks up first

HKEY_LOCAL_MACHINESoftwareJavaSoftJava Runtime EnvironmentCurrentVersion

The key value "current JRE version number" determines whether the "current JRE version number" is 1.4 as the version number, and if so,

Take HKEY_LOCAL_MACHINESoftwareJavaSoftJava Runtime Environment "current JRE version number"

The path of JavaHome is the JRE path.

The JRE path returned by my JDK is: "D:javaj2sdk1.4.2_04jre".

B. Loading the configuration file of jvm.cfg virtual dynamic link library is realized by the function in java.c: ReadKnownVMs

Of.

This function first combines the absolute path of the jvm.cfg file, JRE path + lib+ARCH (CPU framework) + jvm.cfg

The judgment of ARCH (CPU framework) is judged by the GetArch function in java_md.c, in which windows is flat.

There are only two cases: WIN64's' ia64', 'and other cases are' i386'. Mine is i386, so jvm.cfg

The absolute path to the file is "D:javaj2sdk1.4.2_04jrelibi386jvm.cfg". The contents of the document are as follows

Below:

# # @ (#) jvm.cfg 1.703 Copyright 01 Sun Microsystems, Inc. All rights reserved.# SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.# List of JVMs that can be used as an option to java, javac, etc.# Order is important-first in this list is the default JVM.# NOTE that this both this file and its format are UNSUPPORTED and# WILL GO AWAY in a future release.## You may also select a JVM in an arbitrary location with the# "- XXaltjvm=

"option, but that too is unsupported# and may not be available in a future release.#-client KNOWN-server KNOWN-hotspot ALIASED_TO-client-classic WARN-native ERROR-green ERROR

(if you are careful, we will find that there are jvm.dll files in both the "D:javaj2sdk1.4.2_04jreinclient" and "D:javaj2sdk1.4.2_04jreinserver" directories in the JDK directory. 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 starting with'#'), and then reads the jvm parameter specified by the line starting with'-', with one jvm information for each behavior. The first part is the jvm virtual machine name, and the second part is the configuration parameters, such as line:

"- client KNOWN" then "- client" is the virtual machine name, and "KNOWN" is the configuration type parameter, "KNOWN"

Indicates that the jvm.dll of the virtual machine exists, and "ALIASED_TO" is represented as an alias for another jvm.dll, "WARN"

Indicates that the jvm.dll of the virtual machine does not exist, but the runtime replaces the execution with another existing jvm.dll, and "ERROR"

It also means that the jvm.dll of this kind of virtual machine does not exist and the runtime will not find the existing jvm.dll replacement and throw an error directly.

information.

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-Jtel XXaltjvm =". If it is the first way of parameter passing, the CheckJvmType function takes the jvm name after the parameter'- J', and then looks among the known jvm configuration parameters to find the'- 'before removing the jvm name if the same name is found, and directly returns the value; while the second method directly returns the jvm type name after "- XXaltjvm=" or "- JLV XXaltjvm =". If you do not specify either of the above two methods when running java, CheckJvmType takes the jvm name in the first configuration in the configuration file, removes the'- 'before the name and returns 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-client test" 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 run the java program, use the following parameters:

"java-XXaltjvm=D:javaj2sdk1.4.2_04jreinclient test", then ReadKnownVMs

"D:javaj2sdk1.4.2_04jreinclient" will be returned directly; if you do not take the above parameters, execute such as:

"java test", because the first existing jvm in the jvm.cfg configuration file is "- client", so the function

ReadKnownVMs also removes the "-" before the jvm name and returns "client". In fact, all three cases are used.

For the jvm dynamic link library "D:javaj2sdk1.4.2_04jreinclientjvm.dll" to handle the test class, see 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. GetJVMPath function to judge CheckJvmType

Whether the returned jvm type string contains''or'/'if so, take the jvm type string + jvm.dll as the full path of the JVM, otherwise the JRE path + in+jvm type string + jvm.dll as the full path of the JVM.

Looking at the example above, in the first case, the "java-J-client test" jvm.dll path is:

JRE path + in+jvm type string + jvm.dll according to my JDK path is:

"D:javaj2sdk1.4.2_04jre" + "in" + "client" + "jvm.dll".

In the second case, the "java-XXaltjvm=D:javaj2sdk1.4.2_04jreinclient test" path is:

Jvm type string + jvm.dll is "D:javaj2sdk1.4.2_04jreinclient" + "jvm.dll"

The third case "java test" is "D:javaj2sdk1.4.2_04jre" + "in" + "client"

+ "jvm.dll" is the same as in case one. So all three cases are called jvm dynamic link library "D:java"

J2sdk1.4.2_04jreinclientjvm.dll "handles the test class.

Let's take a closer look:

Open the cmd console:

Set up java mount debugging

E:workjava_research > set _ JAVA_LAUNCHER_DEBUG=1

Situation one

E:workjava_research > java-J-client test.ScanDirectory

-_ JAVA_LAUNCHER_DEBUG

JRE path is D:javaj2sdk1.4.2_04jre

Jvm.cfg [0] =->-client-server-hotspot-classic-native-greenjava test.ScanDirectory

-_ JAVA_LAUNCHER_DEBUG

JRE path is D:javaj2sdk1.4.2_04jre

Jvm.cfg [0] =->-client-server-hotspot-classic-native-greenjava-XXaltjvm=D:javaj2sdk1.4.2_04jreinserver test.ScanDirectory

-_ JAVA_LAUNCHER_DEBUG

JRE path is D:javaj2sdk1.4.2_04jre

Jvm.cfg [0] =->-client-server-hotspot-classic-native-green

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.