introduction
I don't like the Java (I don't hate it either), but I enjoy learning about low-level workings. So, I decided to study JVM.
In university, I learned about memory concepts such as heap, stack, data, and text. Recently, while studying the V8 engine, I realized that JavaScript, which I previously underestimated (it was my misunderstanding), operates in a more complex way. Understanding the V8 engine helped me see similarities between its garbage collection and memory structure and that of the CLR. This insight led me to explore the JVM further; if I learn how specific things work, it will help me understand other concepts as well. Additionally, I plan to create a server for a service using Kotlin.
runtime data areas
The JVM's memory structure consists of several key components: the program counter (PC), JVM stack, native method stack, heap, and method area (including the runtime constant pool).
program counter
- The PC indicates the address of the next instruction to be executed
- Each thread has its own independent PC
- During context switches, the current execution point is saved
- When executing a native method, the PC is set to
Undefined
JVM stack
- A new stack frame is created each time a Java method is invoked, contaning the local variable table, operand stack, dynamic link, and return value information
- The JVM stack is thread-private and has the same lifespan as the thread
- The local variable table holds basic data types, object references, and return types. These are stored in local variable slots, each 32 bit in size. if a data type exceeds 32 bits, it uses multiple slots
- The size of the local variable table is determined at compile time and remains fixed during method execution
native method stack
- Similar to the JVM stack, the native method stack is used for executing native methods.
Heap
heap
- The heap is shared among all threads
- It stores object instances and arrays
- Memory allocation in the heap mus be logically consecutive
A more detailed examination of garbage collection will be covered later.
method area
- The method area is also shared among threads
- It holds type data, constants, static variable, and code cached by the JIT compiler
- it resemble the text area in some respects
- Garbage Collection is infrequent in this area, focusing mainly on the constants pool and types
method area.runtime constant pool
- This pool stores meta data about class files when they are loaded by the JVM
direct memory
- Direct memory is not part of JVM runtime
- It allocates physical memory directly
- It allows sharing of memory without copying data between the Java heap and native heap