Bytecrack’s Blog

A friendly place for J Tech savvy’s

JVM details

JVM Details  The Architecture of the Java Virtual Machine

Some runtime data areas are shared among all of an application’s threads and others are unique to individual threads. Each instance of the Java virtual machine has one method area and one heap. These areas are shared by all threads running inside the virtual machine. When the virtual machine loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area. As the program runs, the virtual machine places all objects the program instantiates onto the heap. See Figure 1 for a graphical depiction of these memory areas.

figure1

The Class Loader Subsystem

Every Java virtual machine implementation has a bootstrap class loader, which knows how to load trusted classes, including the classes of the Java API. The Java virtual machine specification doesn’t define how the bootstrap loader should locate classes.

In 1.2, the bootstrap class loader of Sun’s Java 2 SDK only looks in the directory in which the system classes (the class files of the Java API) were installed. The bootstrap class loader of the implementation of the Java virtual machine from Sun’s Java 2 SDK does not look on the CLASSPATH. In Sun’s Java 2 SDK virtual machine, searching the class path is the job of the system class loader, a user-defined class loader that is created automatically when the virtual machine starts up. The 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 Java virtual machine loads a type, it uses a class loader to locate the appropriate class file. The class loader reads in the class file–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. The following information is stored in the method area:

  • Type Information 
    • 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

     

  • The Constant PoolFor each type it loads, a Java virtual machine must store a constant pool. 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.
  • Field InformationFor each field declared in the type, the following information must be stored in the method area:
    • The field’s name
    • The field’s type
    • The field’s modifiers (some subset of public, private, protected, static, final, volatile, transient)

     

  • Method InformationFor each method declared in the type, the following information must be stored in the method area:
    • The method’s name
    • The method’s return type (or void)
    • The number and types (in order) of the method’s parameters
    • The method’s modifiers (some subset of public, private, protected, static, final, synchronized, native, abstract)
    • An exception table

     

  • Class VariablesClass variables are shared among all instances of a class and can be accessed even in the absence of any instance. These variables are associated with the class–not with instances of the class–so they are logically part of the class data in the method area. 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.Constants (class variables declared final) are not treated in the same way as non-final class variables. Every type that uses a final class variable gets a copy of the constant value in its own constant pool. 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 ClassLoaderFor each type it loads, a Java virtual machine must keep track of whether or not the type was loaded 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. This information is stored as part of the type’s data in the method area.
  • A Reference to Class ClassAn instance of class java.lang.Class is created by the Java virtual machine for every type it loads. 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.
  • Method TablesFor each non-abstract class a Java virtual machine loads, it could generate a method table and include it as part of the class information it stores in the method area. A method table is an array of direct references to all the instance methods that may be invoked on a class instance, including instance methods inherited from superclasses. A method table allows a virtual machine to quickly locate an instance method invoked on an object.

The Heap

No matter what object representation an implementation uses, it is likely that a method table is close at hand for each object. Method tables, because they speed up the invocation of instance methods, can play an important role in achieving good overall performance for a virtual machine implementation. Method tables are not required by the Java virtual machine specification and may not exist in all implementations. Implementations that have extremely low memory requirements, for instance, may not be able to afford the extra memory space method tables occupy. If an implementation does use method tables, however, an object’s method table will likely be quickly accessible given just a reference to the object. 
figure2

All content from  http://www.dave-robinson.net/tuning/jvm_details.html 

Advertisements

February 19, 2009 - Posted by | Material

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: