When the . java file is compiled, a .class. file is generated. class has the Java Byte Codes which are the java code transformed into generic machine statements. These byte codes use data such as variable names, literal values, class references, method references, etc. To save the amount of bytes needed to represent this data, byte codes use the Constant pool. The Constant pool has all this data and the byte code has a reference to it.
This link talks about byte codes:
http://www.nessauepa.com.br/blog/2013/08/bytecode-java/
Each file . class has a Constant pool. Also, when the . java is compiled, links are created with all the classes it relates through symbolic references. It is called a symbolic reference because it does not represent the actual memory address. Symbolic references are also in the Constant pool.
You can see the generated content in . class using the following command in cmd:
javap.exe -verbose NomeAbsolutoDoArquivo.class > NomeAbsolutoDeUmArquivoTxt.txt
The contents of the . class in human language will be written in the file Namesabsolutodeumarquivotxt.txt.
In this file it will be possible to see the generated Constant pool.
To execute this command you need to be inside the %JAVA_HOME% bin directory.
When the JVM is instantiated and the class is loaded, the run-time Constant pool is also created which is based on the Constant pool. When a symbolic reference needs to be used, it will be translated into the real address.
This link talks about Constant pool x run-time Constant pool and the symbolic reference:
http://javaguiadoscuriosos.blogspot.com.br/2009/08/primeiramente-ando-meio-sem-tempo-para.html
The JVM, as its name already says, is a virtual machine. This machine will be responsible, among other things, for managing the memory used by the running Java program. The JVM is instantiated when the program is started.
An explanation of how the JVM works can be found in this article:
http://www.devmedia.com.br/entenda-como-funciona-a-java-virtual-machine-jvm/27624
The JVM has some memory areas. Two well-known areas are HEAP and STACK. All objects are in HEAP. The STACK works as follows:
Every time a method is invoked, a frame will be created containing local variables, return value, operand stack and the reference to the run-time Constant pool of the class that has the method. This frame will be added at the top of the stack. When the method finishes running and returning, the frame will be removed from the stack. The stack follows the LIFO data structure (Last In First Out).
A very good explanation about JVM memory management can be found here:
http://luizricardo.org/2014/11/entendendo-as-configuracoes-de-memoria-da-maquina-virtual-java-jvm/
In addition to HEAP, there is an area called NON-HEAP. In this area is located the run-time Constant pool. The classes that will be used by the program will also be loaded in this area. It is in NON-HEAP that the Permgen explained in the article of Luiz Ricardo cited above.
The following image shows the three commented memory areas, shows that the run-time Constant pool is in NON-HEAP and that it is referenced by the frame that is in the STACK:
This link talks in detail about the jvm:
http://blog.jamesdbloom.com/JVMInternals.html#constant_pool
Completion:
What is the Constant pool for?
Save information that will be used by byte code.
What types of data are in the Constant pool?
Literal values, class references, method references, attribute references, constants.
What is the advantage of the Constant pool?
Save the amount of bytes used in byte code.
What’s the difference between the pool and run-time pool?
The Constant pool is in the .class. A run-time Constant pool is in the NON-HEAP, it comes into existence when the class is loaded in the jvm. It is based on the Constant pool.
Okay, the answer was quite complete! If you have any suggestions to improve the question will also be welcome, we can improve the page over time. The answer and the links helped a lot, now I’m programming a little bit in bytecode to understand these internal parts of java more in practice. Several things in java are starting to make much more sense. Thank you for your dedication =) .
– Sérgio Mucciaccia
@Sérgiomucciaccia de nada. Certainly. We’re getting better with time. You can also take a look at the JDK open. See the source code to understand better. Who knows even contribute. http://openjdk.java.net/. I saw that James D Bloom, author of the last link article, learned a lot from reading the code.
– Fagner Fonseca