23/08/2011 22:55

JVM Memory Overview

METHOD AREA


  • Inside a Java virtual machine instance, information about loaded types is stored in a logical area of memory called the method area.
  • When the JVM loads a type, it uses a class loader to locate the appropriate class file.
  • The class loader reads in the class file in a linear stream of binary data and passes it to the virtual machine.
  • The virtual machine extracts information about the type from the binary data and stores the information in the method area.
  • Memory for class (static) variables declared in the class is also taken from the method area.

   JAVAEDITOR     JAVAC                CLASSLOADER                                      JVM
    Java          ->  Class File   -> Linear Stream of Binary Data -> Type Information Stroed in Method Area

TYPE INFORMATION

For each type it loads, a JVM must store the following kinds of information in the method area:

    * The fully qualified name of the type
    * The fully qualified name of the type's direct superclass (unless the type is an interface or class java.lang.Object, neither of which have a superclass)
    * Whether or not the type is a class or an interface
    * The type's modifiers ( some subset of` public, abstract, final)
    * An ordered list of the fully qualified names of any direct superinterfaces 



Inside the Java class file and Java virtual machine, type names are always stored as fully qualified names. In Java source code, a fully qualified name is the name of a type's package, plus a dot, plus the type's simple name. For example, the fully qualified name of class Object in package java.lang is java.lang.Object. In class files, the dots are replaced by slashes, as in java/lang/Object. In the method area, fully qualified names can be represented in whatever form and data structures a designer chooses.

In addition to the basic type information listed previously, the virtual machine must also store for each loaded type:

    * The constant pool for the type
    * Field information
    * Method information
    * All class (static) variables declared in the type, except constants
    * A reference to class ClassLoader
    * A reference to class Class   

THE HEAP

  • Whenever a class instance or array is created in a running Java application, the memory for the new object is allocated from a single heap.
  • As there is only one heap inside a Java virtual machine instance, all threads share it.
  • Because a Java application runs inside its "own" exclusive Java virtual machine instance, there is a separate heap for every individual running application.
  • There is no way two different Java applications could trample on each other's heap data.
  • Two different threads of the same application, however, could trample on each other's heap data.
  • This is why you must be concerned about proper synchronization of multi-threaded access to objects (heap data) in your Java programs.

GARBAGE COLLECTOR



The JVM has an instruction that allocates memory on the heap for a new object, but has no instruction for freeing that memory. Just as you can't explicitly free an object in Java source code, you can't explicitly free an object in Java bytecodes. The virtual machine itself is responsible for deciding whether and when to free memory occupied by objects that are no longer referenced by the running application. Usually, a Java virtual machine implementation uses a garbage collector to manage the heap. 

—————

Back

Contact

ShareYourKnowledge