Java Method Area

Method area
Inside a JVM instance, type information is stored in a memory logical area called the method area. Type information is extracted from the class file by the ClassLoader when the class is loaded. Class (Static) variables are also stored in the method area.

The designer of the JVM implementation determines the internal representation of the type information. For example, a multibyte variable is stored in the class file as Big-endian, but after it is loaded into the method area, its storage form is defined by the JVM on a different platform.

The JVM uses the type information stored in the method area heavily when it runs the app. In addition to maximizing the operational efficiency of the application, the designer should also consider the space problem in the representation of the type information. Depending on the requirements, the JVM's implementation can pursue a balance of time and space.

Because the method area is shared by all threads, you must consider the thread safety of the data. If two threads are trying to find the lava class and the lava class has not yet been loaded, there should only be one thread to load, while the other thread waits.

The size of the method area does not have to be fixed, and the JVM can dynamically adjust to the needs of the application. The same method area does not have to be continuous. The method area can be allocated in the heap (or even the virtual machine's own heap). The JVM can allow users and programs to specify the initial size, minimum, and maximum size of the method area.

The method area also has garbage collection, because Java programs can be dynamically extended by a user-defined ClassLoader, and some classes become garbage. The JVM can reclaim the space occupied by an unreferenced class to minimize the space of the method area.

Type information
For each loaded type, the JVM must store the following types of information in the method area:
A full valid name for this type
The full valid name of the direct parent class of this type (unless the type is interface or
Java.lang.Object, there are no parent classes in either case)
Three modifiers of this type (public,abstract, a subset of final)
Four an ordered list of direct interfaces of this type

The type name appears in the Java class file and in the JVM as a full valid name. In the Java source code, the full valid name is added by the class's owning package name plus a ".", plus the class name
Composition For example, the owning package for class Object is Java.lang, and its full name is Java.lang.Object, but in the class file, all the "." have been
The slash "/" instead, becomes the java/lang/object. The representation of a fully valid name in a method area differs depending on the implementation.

In addition to the basic information above, the JVM also holds the following information for each type:
Type of Chang (constant pool)
Domain (field) information
Method information
All static variables except constants

Constant pool
The JVM maintains a constant pool for each type that is loaded. A constant pool is an ordered set of constants used by this type, including the actual constants (string,
Integer, and floating point constants) and symbolic references to types, fields, and methods. A data item in a pool is accessed through an index, just like an array item.
Because the constant pool stores the symbolic references of all the types, fields, and methods used by a type, it plays a central role in the dynamic linking of Java programs.

Domain Information
The JVM must save information about all fields of the type in the method area and the order in which the fields are declared.
Information about the domain includes:
Domain name
Domain type
Domain modifier (public, private, protected,static,final volatile, a subset of transient)

Method information
The JVM must save the following information for all methods, including the declaration order as the same domain information
Method name
return type (or void) of the method
Number and type of method parameters (ordered)
The modifier of the method (public, private, protected, static, final, synchronized, native, a subset of abstract) in addition to the abstract and native methods, Other methods include the byte code (bytecodes) operand stack of the Save method and the size of the local variable area of the method stack frame
Exception table

Class variable (
Class Variables
Translator: A static variable of a class that is related only to a class, so called a class variable
)
A class variable is shared by all instances of the class, and you can access it even when there is no class instance. These variables are only related to classes, so in the method area they become part of the logic of the class data. Before a JVM uses a class, it must allocate space for each non-final class variable in the method area.

Constants (class variables declared as final) are treated differently, and each constant has a copy in the constant pool. The Non-final class variable is stored in the declaration of its
class information, and the final class is stored in all class information that uses it.

A reference to the class loader
The JVM must know whether a type was loaded by the bootloader or by the user class loader. If a type is loaded by the user class loader, the JVM saves a reference to the ClassLoader as part of the type information in the method area.

The JVM needs this information when it is dynamically linked. When parsing a reference of one type to another, the JVM needs to ensure that both types of ClassLoader are the same. This is critical to how the JVM distinguishes namespaces.

References to class classes
The JVM creates an instance of Java.lang.Class for each loaded type (translator: including classes and interfaces). The JVM must somehow associate this instance of class with the type data stored in the method area.

You can get a reference to this instance by using a static method of class,//a method declared in class Java.lang.Class:
public static Class forname (String className);

If you call forname ("Java.lang.Object"), you will get the class object corresponding to Java.lang.Object. You can even pass this function
Gets any loaded class references in any package, as long as the class can be loaded into the current namespace. If the JVM cannot load the class into the current namespace,
Forname will throw classnotfoundexception.
(translator: A friend who is familiar with COM must have thought that there is also a class object in COM, this class object is the main implementation of a Factory mode, and Java because of the JVM, the middle layer, the class object can be very convenient to provide more information. These two kinds of objects are singleton)

You can also get a reference to a class object through the GetClass () function of either object, GetClass is declared in the object class:
A method declared in class Java.lang.Object:
Public final Class getclass ();
For example, if you have a Java.lang.Integer object reference, you can activate GetClass () to get the corresponding class reference.

With the reference to the class object, you can get the type information stored in the method area by the corresponding class in the run, here are some methods provided by the class classes:
Some of the methods declared in class Java.lang.Class:
Public String getName ();
Public Class getsuperclass ();
public boolean isinterface ();
Public class[] Getinterfaces ();
Public ClassLoader getClassLoader ();

These methods can only return information for a loaded class. GetName () returns the full name of the class, Getsuperclass () Returns the class object of the parent class, and Isinterface () determines whether it is an interface. Getinterfaces () returns a set of class objects, one for each class object, corresponding to a direct parent interface. If not, a zero-length array is returned.
getClassLoader () returns a reference to the class loader that returns null if it is loaded by the startup ClassLoader. All of this information is obtained directly from the method area.

Method table
In order to improve access efficiency, the data information structure stored in the method area must be carefully designed. In addition to the structure discussed above, the JVM's implementation can also add some other data structures, such as method tables. The JVM adds a method table to the type information for each non-virtual class that is loaded, and the method table is a set of direct references to the class instance methods, including the methods inherited from the parent class. The JVM can quickly activate an instance method from a method table. (Translator: The method table here is the same as the virtual function table in C + +, but the Java method is all virtual, and naturally it doesn't have to be a dummy word.) Just as Java declares that there are no pointers, in fact Java is full of pointers. More secure is just a more complete inspection mechanism, but this is at the expense of efficiency, the individual thinks that Java designers always put security on the efficiency, all Java is more suitable for network development)

An example
In order to show how the JVM uses the information in the method area, we have, according to an example,
Look at the following class:
Class Lava {
private int speed = 5; 5 kilometers per hour
void Flow () {
}
}

Class Volcano {
public static void Main (string[] args) {
Lava Lava = new Lava ();
Lava.flow ();
}
}
Let's describe how the bytecode of the first instruction of the main () method is executed. Different JVM implementations vary widely, and this is just one of them.

In order to run this program, you pass "Volcano" to the JVM in some way. With this name, the JVM finds the class file (Volcano.class) and reads it in, from
class file extracts the type information and puts it in the method area, by parsing the bytecode in the method area, the JVM activates the main () method, and at execution time, the JVM maintains a pointer to the current class (Volcano) constant pool.

Note that the JVM has already started executing when the lava class has not yet been loaded. Just like most JVMs, you don't wait for all classes to load before they start executing, it only loads when needed.

The first instruction of main () tells the JVM to allocate enough memory for the class that is listed in the constant pool's first item. The JVM finds the first item with a pointer to the volcano constant pool, discovers that it is a symbolic reference to the lava class, and then checks the method area to see if lava has been loaded.

This symbolic reference is simply the full valid name "Lava" of the class lava. Here we see how important a good data structure is for the JVM to find a class from a name as soon as possible. The JVM's implementations can use various methods, such as hash tables, find trees, and so on. The same algorithm can be used for the implementation of the class forname ().

When the JVM discovers that a class called "Lava" has not yet been loaded, it begins to find and load the class file "Lava.class". It extracts the type information from the class file and places it in the method area.

The JVM then replaces the symbolic reference of the first item of the constant pool with a pointer directly to the lava class of the method area. You can use this pointer to quickly find the lava class. This substitution process is called constant pool parsing (constant pool resolution). Here we are replacing a native pointer.

The JVM is finally beginning to allocate space for the new lava object. This time, the JVM still needs the information in the method area. It uses a pointer to the lava data (a pointer just to the first item of the volcano constant pool) to find out exactly how much space is needed for a lava object.

The JVM is always able to know the space required for a type of object from the type information stored in the method area. However, an object may require different space in different JVMs, and its spatial distribution is different. (Translator: This is the same as in C + +, different compilers have different object models.)

Once the JVM knows the space required for a lava object, it allocates the space on the heap and initializes the variable speed of the instance to the default value of 0. If the parent object of lava also has an instance variable, it is also initialized.

When the reference to the newly generated lava object is pressed onto the stack, the first instruction is ended. The following instruction uses this reference to activate the Java code to set the speed variable to the initial value, 5. Another instruction uses this reference to activate the flow () method of the Lava object.

Java Method Area