Java Developers: You MUST Understand These 5 JVM Memory Areas

Key Takeaways

Hey everyone, welcome back. So far in this series, we have seen how the Java code is compiled. We saw how the bite code is generated. We also covered how as a programmer we can understand the bite code. Then we covered the concepts of class loading. So once the Java program is compiled, it will be executed by the JVM. So we are moving from the compilation to the runtime systems. And the next stop in this chain is to understand the runtime data areas. So whenever we run any program and the GVM starts the execution throughout the execution it manages various runtime data areas and we will cover few of them in this video. So let's get started. [Music] So in this video we will cover all these areas heap method area thread stack program counter and native stacks. Now this is not an exhaustive list. It's not that these are the only areas which exists in JVM. There are a couple of more things that we will understand as we go on with the course. So let's start with the first one which is heap. So heap is probably the most known data area that all the Java programmers are aware about. But it is not the only one as we covered on the previous slide. So what is heap? Heap is a shared memory area within the JVM from which all the object instances are allocated. So when we run any Java program when the JVM starts the execution a major portion of the available memory is allocated as the heap. So suppose this is the memory area that represents the heap. All right. So what is the purpose of the heap? The purpose of the heap is to hold the object instances in a Java program. Whenever a new object is being created, the object will be allocated some memory and that memory comes from the heap. So it stores all the objects. As the program runs, it will create many more objects. And all those objects will be stored on the heap. And when heap does not have enough memory to allocate new objects, JVM kicks off the garbage collection process. So garbage collection process runs in this area which is the heap. So when JVM runs, it identifies all the reachable objects. All other objects which are no longer reachable are collected and their memory is reclaimed so that the memory can be used to allocate new objects. So this is the area where garbage collection runs and this is the area where all the new objects will be stored. There are different ways to monitor the heap. We can use J console. We can also use Java mission control. There are tools like visual VM which can help us to visualize what's going on within the heap as the Java program runs. A heap can be dynamically sized and it can have different regions depending on the GC algorithm. So for example, when we started the program, we allocated this much memory to the heap. There are VM arguments like XMS, XMX that can determine the size of the heap. But it is possible that when JVM starts the execution, it will allocate only a certain portion of that memory to heap. So let's say at time t1 when JVM starts the execution out of this much memory only this area is allocated to the heap. But it does not mean that all the remaining area is useless. All right? As a program runs and it requires more memory over time. The heap can be expanded to use all this available memory. So it can be dynamically sized also it can have different regions. So in a heap a heap can be divided into multiple regions and that can be for example young generation or old generation and within the young generation we can have Eden and survivor spaces. All right. So this is all possible and it depends on the GC algorithm. So we will cover all these details in one of the future videos when we cover the garbage collection. At that point of time we will come back to the same concepts and we will cover all these things in greater depth. The next important data area is the method area. So what does method area store? Method area stores the class level data. In one of the previous videos on the bite code, we covered the bits and pieces of the class structure. So we talked about the overall class structure. We talked about the static fields, the runtime constant pool and the bite code of the method. So all these details are stored in the method area for a class. So it stores the metadata about classes. It stores the static fields. It also stores the runtime constant pool of that class and the actual method code which is the byte code that belongs to a method because the execution unit is the method in a Java program. It is the method that gets executed. All right. So whether it is the bite code, the method signatures, all these things are stored in the method area for a class. So in this example when we create the first object which is A1, we know a new object will be created on the heap. So here is this new object and we know A1 will refer to this particular object. But JVM will also create a java.lang.class object that represents the class and that object will be stored in this method area. So this is the method area. and a new object will be stored and that represents a do.class the class object of A. Now after some time when we create second object which is A2 a new object on the heap will be created. A2 will refer to this object but both of these objects will refer to the same class object which is on the method area. So no matter how many objects we create the distinct objects will be created on the heap but they all will refer to the same class object and that class object is stored in the method area. So that is the purpose of method area. So method area is a concept which has been defined in the JVM specification. How this is implemented in one of the implementations is totally dependent on the implementtor. So for example, hotspot VM can implement method area in one way while Amazon JVM can implement the same area in a different way. So if we talk about just the hotspot VM then this particular area used to be known as perm genen but since Java 8 and 9 hotspot uses metapace as the implementation of method area. This method area when it used to be perm was part of the heap. But in hotspot VM in the new versions when it has been rebranded as meta space it now resides in the native memory rather than in the java heap. So just to summarize whenever the whenever we are creating the objects we know the classes will be loaded by the class loaders and during this process the class loader creates a new object which is java.lang.class and the class objects are stored in the method area while the objects the typical objects are stored on the heap. So this is method area. Let's move on to the next area which is Java stack. Now this is something that we already covered uh when we were discussing byte code. So we know in Java each thread has its own stack. So whenever we create a new thread or whether it is created by JVM let's say when we start the program we know there is always one active thread which is the main thread. So whenever Java creates a thread it is assigned as tag. All right. So these stacks are thread specific which is also uh they they are known as per thread stack. All right thread stack basically. So each thread has its own stack. So for example we have multiple threads t1 and t2. So both of them will have their own stacks. This stack represents t1 and this stack represents t2. Now there is one more thing that threads cannot access each other stack. That is why the data which is stored on the stack is thread safe because if the data is not shared then that data is thread safe. So what is stored on the thread stack? We already covered these things in detail. So you can refer this video but just to summarize a thread stack generally stores local variable table operant stack and return address. So this is the area. The thread stack is the area where JVM creates and appends and removes stack frames. What is stack frame? We know a stack frame represents an executing method. All right. Right? So whenever Java is executing a new method, a new stack frame is pushed here and as soon as method completes the execution, the stack frame will be popped. Now in the stack frame, it has all the metadata which is required for method execution like local variable table. That local variable table is present in the byte code as we covered already in this video. So a local variable table holds the method parameters, their indexes in the bite code, the local variables and similarly the operant stack. What is operant stack? Operant stack is another structure which we will find in the stack frame that is basically used for immediate calculations and passing arguments to the method to the local variable table and all these things. We covered the dry run of this as well. All right. So operint stack is basically a stack where the instructions according to the instructions the uh operants will be pushed and popped and the calculations will be performed by the JVM. So it mainly stores the stack frames as it executes the method and within the stack frame it stores let's say local variable table and oper tag and some other metadata which will be stored on the thread stack. All right. The next memory area is related which is known as program counter register. So what happens when JVM is executing a thread under the hood and thread is executing a method then that thread execution also has something called TC register or program counter register. This register indicates the address or the offset in the byte code array of the currently executing JVM instruction. All right. So when it is executing a methods byte code that method byte code is represented as a bite code array and all the instructions have an index in that bite code array. So PC register indicates the address of the currently executing instruction and that's how the thread knows what is the next instruction that it has to execute. That is the purpose of the program counter. Now this register as the name implies it is a register but it is not an actual register. It is a JVM concept but during the execution the value can be stored in one of the actual hardware registers when the code is compiled and executing as a machine code but that's the part of the runtime how the code is actually executed on a particular system in general PC register is only part of the JVM it is a JVM concept it is not an actual register let's move on and cover the last topic which is the native method stacks All right. So as we talked about that there are Java stacks that whenever a thread is created by Java, it will also be allocated a separate stack. In the same way uh in addition to the Java stack, we have native methods. All right. The methods which are written in C, C++ and which are loaded by JNI. So these method these native methods are executed on a separate stack and this stack is known as native method stack. So during the execution when JVM executes the native methods those methods will be executed on native method stacks. All right. As a Java developer we do not interact with native methods on a day-to-day basis but it is important to understand that this data area exists in the JVM. All right. So that concludes the discussion on the important runtime data areas. Now we only touched the tip of the iceberg. As we go on with the course we will do a deep dive on different topics like when we cover the garbage collection we will understand heap in much more detail. When we cover the jet which is just in time compiler we will understand the method area. Java stacks we have already covered and PC register works with Java stack. This is basically part of the thread execution context to understand what is the next instruction that has to be executed. Native method stack is good to know but we generally do not directly interact with native method stack until and unless you are working on JNI or native method codes. So that is all for this video. In the next video we will cover one more interesting topic on the JVM. So stay tuned. Thanks for watching.