Java running process

 

1. Java concepts
2. JRE Version Control
3. JRE class library search
4. Java Virtual Machine startup and loading class libraries

 

 

1. Java concepts

Java
Byte Code (bytecode)
JVM. dll (Virtual Machine)
JRE (runtime environment)
JDK (Development Framework)
Package (Class Library)

2. JRE Version Control

When java.exe is executed on the console, the operating system looks for jre as follows:
1) First, check whether there is any JRE in the current directory.
2) check whether there is a JRE in the parent directory.
3) Find JRE in the path
4) Registry HKEY_LOCAL_MACHINE/software/export oft/Java Runtime Environment/check which JRE the CurrentVersion key value points

// Process of calling JRE on Windows platform java.exe //
========================================================== ===
Find the JRE path through the function: getjrepath in java_md.c.

<1> This function first calls the getapplicationhome function. The getapplicationhome function calls the windowsapi function getmodulefilenameto obtain the absolute path of the java.exe program. The following uses the JDK installation path as an example: "D: /Java/j2sdk1.4.2 _ 04/bin/java.exe ", and then remove the file name from the absolute path:" D:/Java/j2sdk1.4.2 _ 04/bin ", the last level of directory will be removed. The absolute path is "D:/Java/j2sdk1.4.2 _ 04 ". Then the getjrepath function continues to judge the obtained path +/bin/Java. the Java. whether the DLL file exists. If yes, "d:/Java/j2sdk1.4.2 _ 04" is the JRE path. Otherwise, the obtained "D: /Java/j2sdk1.4.2 _ 04 "path +/JRE/bin/Java. if the DLL file exists, "d:/Java/j2sdk1.4.2 _ 04/JRE" is the JRE path.

<2> if neither of the above conditions exists, search from the Registry (see the getpublicjrehome function ). Function: getpublicjrehome first searches for HKEY_LOCAL_MACHINE/software/javasoft/Java
Runtime Environment/CurrentVersion: the key value is "Current JRE version number". Determine whether "Current JRE version number" is 1.4 as the version number. If yes, take HKEY_LOCAL_MACHINE/software/systoft/Java
Runtime Environment/"Current JRE version number"/javahome path is JRE path. The JRE path returned by my JDK is "D:/Java/j2sdk1.4.2 _ 04/JRE ".

3. JRE class library search

The basic library that comes with JRE is the JRE/lib/RT. jar file, which includes all the class libraries of the Java 2 platform Standard Edition. The version is the same as that of JRE.

In JRE, classloader is responsible for finding and loading the class libraries referenced by the program. The base class library classloader will go to Rt. jar is automatically loaded. Other class libraries and classloader are searched in the path specified by the Environment Variable classpath. The class libraries placed before classpath are first searched, we recommend that you set the path and classpath environment variables before starting the Java program. OS uses the path to find JRE and determine the RT of the base class library. jar location. The classloader of JRE uses classpath to find other class libraries. Then, classloader uses the java. endrosed. Path parameter to specify the path class library before the base class library. Therefore, Java version management is very simple and effective. It may be very primitive, but it is easy to use, so it is not easy to make mistakes.

4. Java Virtual Machine startup and loading class libraries

After the leleexecutes the java.exe xxxcommand, for example, the osfinds jre.osfinds the jredirectory, transmits the parameters of java.exe, loads the JVM. dll of the server version or the JVM. dll of the Client Version, loads the JVM. dll, and gives control to JVM. dll.

Next, JVM. DLL initialization, memory allocation, and other actions, then find the class in the classpath path, find the class, find the main function in the class program entry point, and then execute the program from the main function, during execution, use classloader to dynamically load a series of referenced classes. When the native method is called, JVM. dll tells the OS to find a XX DLL file in the JRE/bin directory and transfer it to the memory, so JNI is called.

// Process for starting JVM. dll on Windows platform java.exe //
========================================================== ===
<1> the configuration file for loading the dynamic Connection Library of the JVM. cfg virtual machine is implemented through the function readknownvms in Java. C.

This function first combines JVM. the absolute path of the cfg file, JRE path +/lib +/arch (CPU architecture) +/JVM. the cfcompetition (CPU architecture) is determined by the getarch function in java_md.c. In this function, there are only two windows platforms: 'ia64' in win64 and 'i386' in other cases '. The absolute path of my JVM. cfg file is "D:/Java/j2sdk1.4.2 _ 04/JRE/lib/i386/JVM. cfg ". The file content is as follows:

<3> the JVM. dll file path is implemented through the function: getjvmpath in java_md.c.

In the preceding two steps, we have obtained the JRE path and JVM type string. The getjvmpath function determines whether the JVM type string returned by checkjvmtype contains '/' or '/'. If yes, the JVM type string +/JVM is used. DLL is the full path of JVM. Otherwise, the JRE path +/bin +/JVM string +/JVM is used. DLL is the full path of JVM.

The following are three examples:

Take a look at the example above,

The first case is "Java-J-client test" JVM. dll path: JRE path +/bin +/JVM type string +/JVM. according to my JDK path, the DLL is "D:/Java/j2sdk1.4.2 _ 04/JRE" + "/bin" + "/client" + "/JVM. DLL ".

In the second case, the path "Java-xaltjvm = D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client test" is a JVM string +/JVM. DLL is: "/Java/j2sdk1.4.2 _ 04/JRE/bin/client" + "/JVM. DLL"

The third case is "Java test": "D:/Java/j2sdk1.4.2 _ 04/JRE" + "/bin" + "/client" + "/JVM. DLL "is the same as Case 1.

In these three cases, the JVM dynamic Connection Library "D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client/JVM. dll" is called to process the test class.

 

Let's further verify:

Open the CMD console:

Set Java load debugging

E:/work/java_research> SET _ java_launcher_debug = 1

Scenario 1

 

E:/work/java_research> JAVA-J-client test. scandirectory

---- _ Java_launcher_debug ----

JRE path is D:/Java/j2sdk1.4.2 _ 04/JRE

JVM. cfg [0] =->-client <-

JVM. cfg [1] =->-server <-

JVM. cfg [2] =->-hotspot <-

JVM. cfg [3] =->-classic <-

JVM. cfg [4] =->-native <-

JVM. cfg [5] =->-green <-

299 micro seconds to parse JVM. cfg

JVM path is D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client/JVM. dll

2897 micro seconds to loadjavavm

JavaVM ARGs:

Versions 0x00010002, ignoreunrecognized is jni_false, noptions is 2

Option [0] = '-djava. Class. Path = .'

Option [1] = '-dsun. java. Command = test. scandirectory'

50001 micro seconds to initializejvm

Main-class is 'test. scandirectory'

Apps 'argc is 0

10208 micro seconds to load main class

---- _ Java_launcher_debug ----

Usage: Java test. scandirectory dir [output file]

Case 2

E:/work/java_research> JAVA-xxaltjvm = D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client test. scandirectory

---- _ Java_launcher_debug ----

JRE path is D:/Java/j2sdk1.4.2 _ 04/JRE

JVM. cfg [0] =->-client <-

JVM. cfg [1] =->-server <-

JVM. cfg [2] =->-hotspot <-

JVM. cfg [3] =->-classic <-

JVM. cfg [4] =->-native <-

JVM. cfg [5] =->-green <-

386 micro seconds to parse JVM. cfg

JVM path is D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client/JVM. dll

2795 micro seconds to loadjavavm

JavaVM ARGs:

Versions 0x00010002, ignoreunrecognized is jni_false, noptions is 2

Option [0] = '-djava. Class. Path = .'

Option [1] = '-dsun. java. Command = test. scandirectory'

49978 micro seconds to initializejvm

Main-class is 'test. scandirectory'

Apps 'argc is 0

9598 micro seconds to load main class

---- _ Java_launcher_debug ----

Usage: Java test. scandirectory dir [output file]

Case 3

E:/work/java_research> JAVA test. scandirectory

---- _ Java_launcher_debug ----

JRE path is D:/Java/j2sdk1.4.2 _ 04/JRE

JVM. cfg [0] =->-client <-

JVM. cfg [1] =->-server <-

JVM. cfg [2] =->-hotspot <-

JVM. cfg [3] =->-classic <-

JVM. cfg [4] =->-native <-

JVM. cfg [5] =->-green <-

381 micro seconds to parse JVM. cfg

JVM path is D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client/JVM. dll

3038 micro seconds to loadjavavm

JavaVM ARGs:

Versions 0x00010002, ignoreunrecognized is jni_false, noptions is 2

Option [0] = '-djava. Class. Path = .'

Option [1] = '-dsun. java. Command = test. scandirectory'

50080 micro seconds to initializejvm

Main-class is 'test. scandirectory'

Apps 'argc is 0

10215 micro seconds to load main class

---- _ Java_launcher_debug ----

Usage: Java test. scandirectory dir [output file]

The three JVM paths are:

JVM path is D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client/JVM. dll

Other cases

E:/work/java_research> JAVA-J-server test. scandirectory

---- _ Java_launcher_debug ----

JRE path is D:/Java/j2sdk1.4.2 _ 04/JRE

JVM. cfg [0] =->-client <-

JVM. cfg [1] =->-server <-

JVM. cfg [2] =->-hotspot <-

JVM. cfg [3] =->-classic <-

JVM. cfg [4] =->-native <-

JVM. cfg [5] =->-green <-

377 micro seconds to parse JVM. cfg

JVM path is D:/Java/j2sdk1.4.2 _ 04/JRE/bin/Server/JVM. dll

2985 micro seconds to loadjavavm

JavaVM ARGs:

Versions 0x00010002, ignoreunrecognized is jni_false, noptions is 2

Option [0] = '-djava. Class. Path = .'

Option [1] = '-dsun. java. Command = test. scandirectory'

62382 micro seconds to initializejvm

Main-class is 'test. scandirectory'

Apps 'argc is 0

12413 micro seconds to load main class

---- _ Java_launcher_debug ----

Usage: Java test. scandirectory dir [output file]

E:/work/java_research> JAVA-xxaltjvm = D:/Java/j2sdk1.4.2 _ 04/JRE/bin/server test. scandirectory

---- _ Java_launcher_debug ----

JRE path is D:/Java/j2sdk1.4.2 _ 04/JRE

JVM. cfg [0] =->-client <-

JVM. cfg [1] =->-server <-

JVM. cfg [2] =->-hotspot <-

JVM. cfg [3] =->-classic <-

JVM. cfg [4] =->-native <-

JVM. cfg [5] =->-green <-

376 micro seconds to parse JVM. cfg

JVM path is D:/Java/j2sdk1.4.2 _ 04/JRE/bin/Server/JVM. dll

2937 micro seconds to loadjavavm

JavaVM ARGs:

Versions 0x00010002, ignoreunrecognized is jni_false, noptions is 2

Option [0] = '-djava. Class. Path = .'

Option [1] = '-dsun. java. Command = test. scandirectory'

62725 micro seconds to initializejvm

Main-class is 'test. scandirectory'

Apps 'argc is 0

8942 micro seconds to load main class

---- _ Java_launcher_debug ----

Usage: Java test. scandirectory dir [output file]

Summary:

1. You can use the pathpattern and java.exe files for jrechecking.

2. You can also search for the registry, such as writing the following registry file.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE/software/kerberoft]

[HKEY_LOCAL_MACHINE/software/javasoft/Java Runtime Environment]

"CurrentVersion" = "1.4"

[HKEY_LOCAL_MACHINE/software/javasoft/Java Runtime Environment/1.4]

"Javahome" = "D: // Java // j2sdk1.4.2 _ 04 // JRE"

 

 

 

#

# @ (#) JVM. cfg 1.7 03/01/23

#

# Copyright 2003 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

# "-Xxaltjvm = <jvm_dir>" 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 the following in the JDK Directory: "D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client" and ": /Java/j2sdk1.4.2 _ 04/JRE/bin/Server both directories have JVM. DLL file. Java manages these different versions of JVM. dll through the JVM. cfg configuration file .)

 

The readknownvms function reads the configuration content in this file into a global variable of the JVM configuration structure. This function skips the annotation (the row starting with '#') first ), then read the JVM parameters specified in the row starting with '-'. Each row contains a JVM information. The first part is the JVM Virtual Machine name, and the second part is the configuration parameters, such as the line: "-client known" indicates "-client" indicates the Virtual Machine name, "known" indicates the configuration type parameter, and "known" indicates the JVM of the virtual machine. dll exists, while "liased_to" indicates another JVM. DLL alias. "Warn" indicates the JVM of the virtual machine. the DLL does not exist, but other existing JVM will be used during runtime. DLL replacement execution, while "error" also indicates the JVM of this type of virtual machines. the DLL does not exist and does not find the JVM. DLL replacement directly throws an error message.

<2> when running a Java program, specify the virtual machine used to determine whether the result is determined by Java. function in C: checkjvmtype. This function checks whether JVM parameters are specified in the Java running parameters and then the JVM read from the readknownvms function. the CFG data structure is searched to specify different JVM types. DLL ). There are two ways to specify the JVM type, one is based on JVM. specify the JVM name in the cfg file. The second method is to directly specify the name. The methods they run are "Java-j <JVM. JVM Name> "and" Java "in cfg
-Xxaltjvm = <JVM type Name> "or" Java-J-xxaltjvm = <JVM type Name> ". For the first parameter transfer method, the checkjvmtype function takes the JVM name after the '-J' parameter, then, find from the known JVM configuration parameters. If the same name is found, remove the '-' before the JVM name to directly return the value. The second method, the JVM type name after "-xxaltjvm =" or "-J-xxaltjvm =" is directly returned. If no one of the above two methods is specified when running Java, checkjvmtype takes the JVM name in the first configuration in the configuration file, and removes '-' before the name to return this value. The Return Value of the heckjvmtype function is combined with the JRE path in the following function to form the absolute path of JVM. dll.

 

For example, if "Java-J-client test" is used to run a Java program, readknownvms reads the parameter "-client" and searches for the JVM. whether the JVM name is "-client" is included in the parameters read by CFG. If yes, the "-" before the JVM name is removed and the "client" is directly returned "; if you use the following parameters when running a Java program:

"Java-xxaltjvm = D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client test", readknownvms returns "D: /Java/j2sdk1.4.2 _ 04/JRE/bin/client "; if the preceding parameter is not included, execute" Java test "because. the first JVM In the CFG configuration file is "-client". Therefore, the readknownvms function also removes "-" before the JVM name and returns "client ". In fact, the third case uses "D:/Java/j2sdk1.4.2 _ 04/JRE/bin/client/JVM. dll "the JVM dynamic connection library processes the class test. For details, see the getjvmpath function below.