One of the major benefits of the Java language in comparison with other object oriented languages (like C++) is that programmers do not have to handle memory allocation during execution of the program. It is totally delegated to the garbage collector (GC) which is in charge of removing unused objects to release memory.
If objects stored in Survivor buckets, survive to other GC visits they are then moved into the Tenured generation (or Old generation) bucket until they are destroyed by the Garbage Collector.
JVM memory organisation
The memory of the JVM is first slitted into 2 parts :
- the heap memory
- the non heap memory
The heap memory
The heap is devided into two generations: The Young Generation and the Tenured Generation.
The heap contains all Objects created during execution, this space should be frequently visited by the GC in order to clean up unused objects (=objects not referenced anymore). It is also slitted into different section according to the lifetime of the objects. Initially all objects are stored into the Eden section. Most of this objects will then be destroyed at the next GC visit because they are not used anymore. But some of them need to be kept because they have a longer lifetime and they will be used in the future. Therefore they are moved into the Survivor bucket. In the Survivor bucket GC calls are less frequent than in the Eden bucket. This two buckets represent the Young generation and contains all the “newly created” objects.
The non heap memory
It comprises of ‘Method Area’ and other memory required for internal processing.
- Method Area
- The method area is responsible for storing class information. The Class-Loader will load the bytecode of a class and will pass it to the JVM. The JVM will generate an internal class representation of the bytecode and store it in the method area. The internal representation of a class will have the following data areas:
- Runtime Constant Pool - Numeric constants of the class of types int, long, float or double, String-constants and symbolic references to all methods, attributes and types of this class.
- Method Code - The implementation (code) of all methods of this class including constructors etc.
- Attributes - A list of all named attributes of this class.
- FieldsValues of all fields of this class as references to the Runtime Constant Pool
- Java Stacks or Frames
- Every time a method is invoked a stack frame is created and pushed onto the Java Stack. When the method terminates, this frame is popped off the stack. Thus, the top-most frame of the Java stack always belongs to the method that is currently being executed by the JVM.
In addition to the heap and method area, that are available for all threads of a JVM, every thread also has exclusive access to memory that is created for each thread:
- PC Register The Program Counter register. The register points to the current JVM instruction of the method the thread is executing, if the method is not a native method. If it is a native method the content of the PC register is not defined.
- Java Virtual Machine Stack Each thread gets its own stack on which so called Frames are pushed for each method the thread currently executed. This means that there can be many frames on the stack for nested method calls – but there is only one frame active at the same time for one thread. The frame contains the local variables of the method, a reference to the Runtime Constant Pool of the method’s class and an operand stack for the execution of JVM operations. (The JVM is a stack machine!)
- Native Methode Stack Native methods get its own stack, the so called „C-Stack“.
Structure of JVM
Consequences
Bad tuning of the JVM can lead to several issues. The most obvious is that you set memory parameters too low to run your application so it cannot even start. But there are others.
Errors
If your memory parameters are too low you will probably have to tackle OutOfMemoryError since your application requires more space than what you allocated.
Non optimal performance
If your memory parameters are too low you will decrease the performance of the application. Indeed, the GC has to run very often in order to maintain the available space, which requires some time and also needs to stop the application.
Excessive footprint
On the other hand, allocating a huge memory to the JVM is also a bad practice because you will use (consume) much more than what you need and also because other resources won’t be able to use this unused space : OS, database, …. Therefore this may lead to non optimal performance as well.
Reference http://batterywalam.wordpress.com/category/j2ee-diagnostics/jvm-tuning/jvm-memory-organization
No comments:
Post a Comment