JVM Bytecode Made Simple: Essential Concepts

Key Takeaways

Hey guys, welcome back. With this video, I'm going to start a new series on JVM and internals. So throughout this series, we will cover a variety of topics like the basic understanding of byte code, the class loading mechanism, the memory architecture of Java VM, the garbage collection and GC algorithms, how GC works, how to take the heap dump, how to analyze the heap dump. Then we will also cover JIT which is just in time compiler. We will also cover the profiling and tuning so on and so forth. So you get the idea. This is going to be an interesting and exciting series. And if you are interested in how Java code works under the hood, this is for you. As for this video, we'll start from the basics. From the step one, we will cover the basic understanding of byte code. So, we will learn how to check out the byte code, how to deassemble the class. We will understand the class structure and different pieces and concepts that we will see in the generated byte code. So, let's get started. [Music] So as we know when we write a Java program first of all we compile it. When we compile it we get a doclass file which has the byte code and this byte code is then executed by JVM. So in order to run the program JVM needs the byte code which is contained in the doclass file. And this is where we will spend the time. We will understand what goes into the class file. what is the bite code and how do we understand the bite code. So the first thing is how do we check out what goes on in the class file. Okay. So how do we check the actual bite code? Now there are various ways to check out the byte code. But if you want to check the actual bytes of streams which are written into this class file then it's a little bit difficult because if you try to open the dotclass file using textpad or notepad you won't be able to see the actual content because that is the streams of bytes. So how do we see it? There are different softwares available which you can install which can help you to open the dotclass file and one of them is hex editor which is hxt and here you can see the screenshot. So we will spend a couple of minutes on this tool. So here we have that hex editor which is hxt and what I have done I have opened a simpleclass file in this tool. So you can see this tool has opened or loaded the doclass file and this is simply a stream of bytes. The first thing you set in this tool is the width which is the 16 byt in this case but you can change it to 8 16 32 whatever it is. This is just for the display purpose. It does not change the content of your class file. So as I have selected it to be 16 bytes. So you can see there are 16 bytes 0 to 15 because this is hex. So total 16 bytes and here we have the offset. Offset is simply because as I said this is a stream of bytes. So in this stream there are offset or indexes of the set of those 16 bytes. So you can see at offset zero we have these first 16 bytes from the class file and offset 10 which is in the hex value. So you can convert it to decimal we have the next 16 bytes. So this is showing me the exact content of myclass file which is simply the bytes. All right. Now this is not much useful for us because this is not human readable. But there is one takeaway from this is that the byte code in the doclass file is basically a sequence of bytes. So if you consider it as an array and there are different bite. Okay. So these are different bite contents. So each particular block will have an index which is the offset and the width or the length of that block. Okay. So that's how the content will be read from the doclass file. Now we are not going to use hxt because this is not friendly as I said but this is just to illustrate how the bite code looks in the class file. We will see a friendly way or a familiar way of understanding the bite code in a short while. But before that there is one more important concept that we have to cover and that is the operant stack. The concept of operant stack is very important to understand because almost always when JVM is executing the bite code it is interacting with this operant stack. This is used as a simple stack which supports push and pop operations. So how that works is that some byte code instructions push the values to this operent stack while other instructions pop the values from this operant stack and in this way byte code is executed by the JVM using the oprint stack. So we will see a dry run soon. The other thing to understand is where the stack is placed. So on the screen you see a thread stack in Java. Each thread gets its own stack and inside that thread stack we have different stack frames. So each executing method gets its own stack frame and inside a particular stack frame we have the operant stack. So the operant stack is a per method structure that means each method would have its own stack frame and an operant stack. Now let's spend some time on thread stack, stack frame and operant stack. All right. So we know in Java there is at least one active thread which executes the code and that is the main thread. So even if you don't create any custom thread, JVM will always create a main thread. And in Java, each executing threads gets its own stack. And this is also known as thread stack or thread VM stack. So for example, when we run the Java program and if we are not creating any other custom thread, we know there will be one main thread. So that main thread gets a stack on the VM memory and this is called a thread stack. So at any point of time there could be n number of stack frames active in JVM. So this is also a thread stack let's say for any thread. All right. Now what happens a thread is executing some code and in Java that code is ultimately written in the methods. So at a particular point of time a thread is executing a method. When a method is executed JVM creates a stag frame and push it onto the thread stack. So suppose this is thread T1 and this thread T1 executes a method M1. So what will happen? JVM will create a stack frame for M1 and it will be pushed onto the T1 stack. All right. Now the stack frame on top of the stack always represents the currently executing method. So this is the M1 method. Now let's say from the method M1 you call another method M2. So now the execution is changing. M2 will be called. So what JVM will do? it will create a new stack frame for M2 and it will be pushed onto this thread stack. So this is the new top and this represents the method execution for M2. So in the same way each executing method gets its own stack frame. All right. So this is stack frame. So when a method executes it has some code which is the bite code at runtime and it has some parameters. it has a return value and all of this is stored in the stack frame or at least the metadata depending on the case. So here we have a stack frame and all this metadata and sometimes some values will be stored in the stack frame which is required for the method execution. Now along with this in this stack frame we have the oper stack which is a simple stack which supports push and pop operations. So what would happen for example for a methods byte code let's say there are some byte code instructions and one of them says that load constant one this is a simplified version the another instruction says load constant 2 and the third instruction suppose says add c1 and c2 so here we have c1 and c2 so what would happen for the first instruction on the oper stack one will be pushed all Right? For the second instruction, another value will be pushed onto the operating stack which is this one. Okay? And for the third instruction which is to add the values, what JVM will do, it will pop two, it will pop one, it will perform the operation which is 2 + 1 equals to three. And depending on the code, this three might be pushed back onto the operint stack. So that's how byte code instructions are executed using the operint stack by the JVM. So once again what is the placement for each thread? We have the stack. All right. And inside the stack we have the stack frame and inside the stack frame we have the operant stack. All right. Next we will learn line number table and local variable table. So in the generated byte code you will see something called line number table which looks something like this. So under the line number table you have several mappings like line 3 col 0, line 4 col 2. We will see a quick example on that. And the second thing is local variable table. So under the local variable table in the byte code section you will see something like this a table which says start zero length 22 in this case 32 slot zero name which is the arcs and the signature. So let's try to understand what are these things. And here you can see a simple example of a bite code. So in this section you see a section line number table which has only one mapping and similarly local variable table which also has a single row and this is for constructor that's why this is pretty simple but you get the idea in the generated by code we have the sections like line number table and local variable table. So let's try to understand now let's start with the line number table. Okay. So this is the line number table in the generated byte code and it has a simple mapping line 1 0. What it means is that line number table is used to maintain the mapping of byte code instruction offset to the source code line numbers. So here line number one says that line number one in the source code which is the Java file maps to the byte code offset zero. That's it. And if you remember we started the video with the same idea that generated byte code is actually a sequence of bytes. And in that sequence we have the indexes which are called offsets and the width of the section. So this is the offset we are talking about. So in this case line number table says that this particular line in the source code is corresponds to this particular bite code offset. That is the purpose of line number table. All right let's move on to the local variable table. So this is also simple local variable table as the name suggests hold the information of the local variables because method would have some local variables like arguments method arguments or the return result or if this is a no argument constructor even then it would have a local variable which is the this reference and you can see it here in the constructor there is a single row and it says that at slot zero which is in the table at index zero you have the local variable which is this the signature of this is l main which is a special uh you can say name given to the constructor and it starts from the offset zero with a length five. So what that means is it is instructing JVM that if you start from the offset zero and pick a value with length five then you will find the local variable this which is required in this constructor because as we covered this is a sequence of bytes right the byte code is a sequence of bytes and we have the offset and we can also give the width or the length. So for example pick this section and this represents this in this case. All right. Now here is another example in the same file for a different method. So in this case you can see a lot more entries in the line number table. So this says that line number three in the source code belongs to bite code offset zero. Line number four is basically offset two. Line number five is basically offset 9 so on and so forth. And in the same way in the local variable table in this method we have three local variables. This is slot zero which means basically slot in this table. So there are three rows. So 0 1 and two. This is first index. This is second slot. So there are three variables. The variable at zero is arcs of type string array. Which means you know uh the variable that we generally give in the main method like this. So this is the slot zero value. Now at first slot we have uh another variable the name is I signature is I which means integer and similarly at first index we have another local variable with name sum and again integer. So suppose JVM has to pick this particular local variable which is arcs. What it will do? It will start from the bite code offset zero will read a length of 32 and it will get the arcs. And similarly to read the sum what it will do it will start from the bite code offset 2 and read a width of 30. So that is the purpose of local variable table. It tells JVM what are the local variables available in this method and how to read them. What is their type. All right. So that's all for this video. We laid the foundation by understanding the core concepts like operant stack, the line number table and the local variable table and how the byte code is essentially a sequence of instructions, a sequence of bytes. Now these concepts are actually the building blocks before we can dive deep in the bite code and we will continue the journey in upcoming videos. I will see you in the next video. Thanks for watching.