Several types of data is stored in the constant pool including

For example the following code:

 Object();

Would be written in byte code as follows:

:                 
 :  
 :       "( ) V

The  opcode (operand code) is followed by the  operand. This operand is an index into the constant pool and therefore is referencing the second entry in the constant pool. The second entry is a class reference,this entry in turn references another entry in the constant pool containing the name of the class as a constant UTF8 string with the value . This symbolic link can then be used to lookup the class for java.lang.Object. The  opcode creates a class instance and initializes its variables. A reference to the new class instance is then added to the operand stack. The  opcode then creates an extra copy of the top reference on the operand stack and adds this to the top of the operand stack. Finally an instance initialization method is called on line 2 by . This operand also contains a reference to the constant pool. The initialization method consumes (pops) the top reference off the operand pool as an argument to the method. At the end there is one reference to the new object that has been both created and initialized.

If you compile the following simple class:

 org.jvminternals;
<span class="keyword">public <span class="keyword">class SimpleClass {
<span class="keyword"&gt;public</span> <span class="keyword"&gt;void</span> sayHello() {
    System.out.println(<span class="constant_value"&gt;"Hello"</span>);
}
}

The constant pool in the generated class file would look like:

":()V
   #2 = Fieldref           #18.#19        
   #3 = String             #20            
   #4 = Methodref          #21.#22        
   #5 = Class              #23            
   #6 = Class              #24            
   #7 = Utf8               
   #8 = Utf8               ()V
   #9 = Utf8               Code
  #10 = Utf8               LineNumberTable
  #11 = Utf8               LocalVariableTable
  #12 = Utf8               this
  #13 = Utf8               Lorg/jvminternals/SimpleClass;
  #14 = Utf8               sayHello
  #15 = Utf8               SourceFile
  #16 = Utf8               SimpleClass.java
  #17 = NameAndType        #7:#8          ":()V
  #18 = Class              #25            
  #19 = NameAndType        #26:#27        
  #20 = Utf8               Hello
  #21 = Class              #28            
  #22 = NameAndType        #29:#30        
  #23 = Utf8               org/jvminternals/SimpleClass
  #24 = Utf8               java/lang/Object
  #25 = Utf8               java/lang/System
  #26 = Utf8               out
  #27 = Utf8               Ljava/io/PrintStream;
  #28 = Utf8               java/io/PrintStream
  #29 = Utf8               println
  #30 = Utf8               (Ljava/lang/String;)V

The constant pool contains the following types:

The exception table stores per-exception handler information such as:

Start point
• End point
• PC offset for handler code
• Constant pool index for exception class being caught

If a method has defined a try-catch or a try-finally exception handler then an Exception Table will be created. This contains information for each exception handler or finally block including the range over which the handler applies,what type of exception is being handled and where the handler code is.

When an exception is thrown the JVM looks for a matching handler in the current method,if none is found the method ends abruptly popping the current stack frame and the exception is re-thrown in the calling method (the new current frame). If no exception handler is found before all frames have been popped then the thread is terminated. This can also cause the JVM itself to terminate if the exception is thrown in the last non-daemon thread,for example if the thread is the main thread.

Finally exception handlers match all types of exceptions and so always execute whenever an exception is thrown. In the case when no exception is thrown a finally block is still executed at the end of a method,this is achieved by jumping to the finally handler code immediately before the return statement is executed.

In addition to per-type run-time constant pools the Hotspot JVM has a symbol table held in the permanent generation. The symbol table is a Hashtable mapping symbol pointers to symbols (i.e. ) and includes a pointer to all symbols including those held in run time constant pools in each class.

Reference counting is used to control when a symbol is removed from the symbol table. For example when a class is unloaded the reference count of all symbols held in its run time constant pool are decremented. When the reference count of a symbol in the the symbol table goes to zero then the symbol table knows that symbol is not being referenced anymore and the symbol is unloaded from the symbol table. For both the symbol table and the string table (see below) all entries are held in a canonicalized form to improve efficiency and ensure each entry only appears once.