![]() |
|||
![]() ![]() |
![]() |
|
![]() |
JVM Registers and a Stack-Based Architecture In the Intel and Motorola architectures, registers are used for almost everything, due to the fact that both architectures are register-based. Say you want to add the numbers 2 and 3. As shown in Figure 1.4, in a register-based architecture you would load the value 2 into a register (memory storage device), and then load the value 3 into another register.
Once the values are loaded, you would load an And operation code value into yet another register to instruct the processor to perform the operation. So essentially, you would use registers as the means of communicating with the processor. However, different makes and models of processors contain various types and quantities of registries, making it impossible to create an all-encompassing virtual architecture based on registers. The solution the JVM opted for is a stack-based architecture. The JVM was designed to function in any machine architecture while retaining the ability to be implemented directly on silicon. To achieve this, and maintain compatibility with architectures with various types and quantities of register devices, the JVM utilizes a stack-based architecture. Revisiting the 2 plus 3 problem, you can see the inherent difference between the two architectures. As shown in Figure 1.5, in a stack-based architecture the value of 2 is pushed onto a stack, then the value 3 is pushed onto the same stack, and finally the add operation code is pushed onto the same stack.
Once the values and the add instruction have all been pushed onto the stack, the processor is directed to start executing the instruction on the stack by setting a single register value to initiate execution. In this manner, the stack-based model can execute the same add operation with one register and one stack. From the stack-based example in Figure 1.4, you can see that the JVM requires the use of a few registers. But, the usage of these registers varies drastically from the example displayed in Figure 1.5. The following describes each of the four JVM registers and its use. JVM Registers:
Single Stack Resource As mentioned in the previous section, the entire JVM architecture revolves around a single, 32-bit wide stack resource. However, this stack is not a simple, everyday stack of 32-bit wide elements. Elements are pushed onto and popped off of the stack in the same manner as they are in a normal FIFO (First In First Out) programmatic stack. The difference lies in how the JVM stack is partitioned. The JVM is partitioned into three separate regions. The following describes each of these regions and their roles in the larger JVM stack picture. Later, this chapter steps through the execution of a class file to demonstrate how these regions are used. JVM Stack Regions:
Garbage Collection Heap The concept of garbage collection in Java is sometimes a difficult thing to grasp, so take a step back and compare it to how you consume groceries. You go to the store, purchase your groceries, consume your goods, and then dispose of the refuse. Now, say that everything you buy is 100% recyclable so that, once you consume an item, it goes right back to the grocery store to be restocked for another consumer. In the same way, memory resources may be consumed and then directly reused. In this way the Garbage Collection Heap device of the JVM allows for the recycling of used memory resources. The Garbage Collection Heap device is the central facility for all memory storage devices. If your program wants to store a number, a memory device is allocated from the Garbage Collection Heap to facilitate your request. Once your program is finished with the storage device, the memory goes back to the heap for restocking. Restocking or garbage collection is not something defined in the JVM specification. That is, not all JVM implementations perform garbage collection in the same way. Some JVMs may restock the memory at the time it is returned to the heap. Other implementations may wait until the heap, or store, is completely empty before they restock the shelves. Either way, the Garbage Collection Heap device is responsible for allocating and reusing memory resources. How and when its duties are performed is a JVM implementation issue. The Method Storage Area As the name implies, the Method Storage area is the primary memory storage device for all methods found in the executing class. Later in this chapter, in the section named Execution of a Class file, when you diagram the execution of a class file, you will revisit this area of the JVM. But for now, just think of it as the general storage device for all Java executable code.
|
![]() |
|