JVM, Part 5- Runtime data areas ( Method Area)

In this post I will explain about the runtime data areas of JVM.

When a Java virtual machine runs a program, it needs memory to store many things, including bytecodes and other information, it extracts from loaded class files, objects instantiated, parameters to methods, return values, local variables, and intermediate results of computations. The Java virtual machine organizes the memory it needs to execute a program into several runtime data areas.

 

METHOD AREA:

1. Information about loaded types are stored in the method area. 
2. when the types are loaded then class loader reads the required file and then that is passed to the JVM and then JVM extract the information and store those in method area.
3. Memory for static variables declared in the class is also taken from the method area.
4. All threads share the same method area, so access to the method area's data structures must be designed to be thread-safe. 
5. The size of the method area need not be fixed,it can expand and contract the method area to fit the application's needs. Also, the memory of the method area need not be contiguous. 
6. The method area can also be garbage collected.As Java programs can be dynamically extended via user-defined class loaders, classes can become "unreferenced" by the application. If a class becomes unreferenced, a Java virtual machine can unload the class (garbage collect it) to keep the memory occupied by the method area minimum.

About loaded types, what kind of information is stored in method area?

 

About loaded types jvm stores following information:

1. full qualified name of the type.
2. full qualified name of type's direct superclass (except java.lang.Object and interface)
3. type that is loaded, is that class or interface?
4. modifiers that is used with class 
5. constant pool for this type.
6. all information about static variables except constant.
7. field information as well as method information.
8. reference to class ClassLoader and class Class.

Constant Pool

1. A constant pool is an ordered set of constants used by the type, including literals (string, integer, and floating point constants) and symbolic references to types, fields, and methods. 
2. Entries in the constant pool are referenced by index, much like the elements of an array. 
3. As it holds symbolic references to all types, fields, and methods used by a type, the constant pool plays a central role in the dynamic linking of Java programs.

Field Information

1. The field's name
2. The field's type
3. The modifiers being used ( public, private, protected, static, final, volatile, transient) 
4. It also store the information about the order in which fields are declared inside the class or interface.

Method Information

1. The method's name
2. The method's return type ( or void)
3. The number and type of method's parameters.
4. The method's modifiers.
5. In case of non-abstract methods and non-native methods , it also stores method's bytecodes
6. The sizes of the operand stack and local variables sections of the method's stack frame.
7. The Exception table. 

Class variables

1. Before a Java virtual machine uses a class, it must allocate memory from the method area for each non-final class variable declared in the class.
2. Constants (class variables declared final) are not treated in the same way as non-final class variables. 
3. Every type that uses a final class variable gets a copy of the constant value in its own constant pool.
4. As part of the constant pool, final class variables are stored in the method area--just like non-final class variables. But whereas non-final class variables are stored as part of the data for the type that declares them, final class variables are stored as part of the data for any type that uses them.

A reference to Class ClassLoader

1.  Java virtual machine  keep track of how type was loaded weather via the bootstrap class loader or a user-defined class loader. For those types loaded via a user-defined class loader, the virtual machine must store a reference to the user-defined class loader that loaded the type. 
2. The virtual machine uses this information during dynamic linking.When one type refers to another type, the virtual machine requests the referenced type from the same class loader that loaded the referencing type.
3. This process of dynamic linking is also central to the way the virtual machine forms separate name spaces

A reference to class Class

1. An instance of class java.lang.Class is created by the Java virtual machine for every type it loads. 
2. The virtual machine must in some way associate a reference to the Class instance for a type with the type's data in the method area.  
3. Your Java programs can obtain and use references to Class objects. One static method in class Class, allows you to get a reference to the Class instance for any loaded class: public static Class forName(String className);
4. You can use forName() to get a Class reference for any loaded type from any package, so long as the type can be (or already has been) loaded into the current name space. If the virtual machine is unable to load the requested type into the current name space, forName() will throw ClassNotFoundException.  
5. After getting reference to a Class object, you can find out information about the type by invoking methods declared in class Class. If you look at these methods, you will quickly realize that class Class gives the running application access to the information stored in the method area.
6. Some of the other useful methods that can be useful at this level to introspect about the loaded classes are as follows:

7. public String getName();
   public Class getSuperClass();
   public boolean isInterface();
   public Class[] getInterfaces();
   public ClassLoader getClassLoader();

     

----  NEXT POST WILL BE ABOUT HEAP AREA OF JVM, 

---KEEP VISITING