1. Overview
Regardless of specific implementation, first take a look at what’s described in JVM SPEC. And most of post is talking about server VM, however, where applicable you can reference for client VM.
Given the assumption of having knowledge of conventional (from some point of view, Java itself may become a conventional language, so in this case it indicates those compiled language invented before Java) compiled languages and compiler/linker/loader, it is very easy to understand the internal structure (more accurately, the structure of the JVM at runtime), and may be helpful to better understand conventional compiled languages.
2. Abstract Structural Element
This section is to give concepts of elements that consists the runtime jvm structure. They’re supposed to be independent of specific data structure implementation. At the beginning of each element subsection, important properties are listed.
pc
- private to each thread
- execution (which means it supports for the execution)
- created when each thread is created
Program counter, which indicates the jvm instruction currently being executed. jvm can support many threads of execution at once and each jvm thread has its own pc. Unlike many conventional language, Java programming language is pure OO, which means no real global “thing” are allowed. Giving some thoughts on the execution of a java program for which the main method is the entry in which the control may flow to constructor of some class, static method of some class, method of some class instance, and so on, you’ll quickly come to the conclusion, just as what’s stated in JVM SPEC, that at any point in time each jvm thread is executing the code of a single method. For normal (non-native) method, pc leads to the address the jvm instruction currently being executed, while for native method, pc is undefined which means it is totally up to specific jvm implementor.
Method Area
- shared by threads
- program (which means it is the “mapping” of your program into jvm)
- created at jvm start-up
Analogous to runtime structure of a program written in conventional language, a code area exists in jvm structure. In jvm, it is called a method area, though it doesn’t only include code for method. It is shared by all threads of execution in jvm. It can contain per-class structure such as runtime constant pool and code of class itself, field data and method data, method (including constructor) code. In java terms, it contains the reflective data with regard to class and methods of a java program. This means as long as new classes (or in a special case, the interned string) are loaded, this area increases.
Constant Runtime Pool
- private to each class
- program
- created at compile time and “mapped” when each class is loaded
- part of method area
Refers to here (chapter 3, jvm spec) and here (chapter 4, jvm spec) for more information.
Frames
- private to each thread (or more specifically to each method, correct me)
- execution
- created at method invocation
- part of collection of frames
Only with method area (the code understandable by jvm), the program is not alive, since method area is static, which means the size is fixed at compile time or load time. So just like activation record with regard to conventional program, frames refer to the real execution of a program. Each thread of execution manages its own collection of frames that are not shared with other threads. This collection may itself be considered an abstract structure element which we will talk about later. Whenever a new invocation of method take place, a new frame is dynamically created, and discarded as the invocation completes, normally or abruptly. The method may be non-native or native.
Each frame consists of a series of local variable of the method, and the status of the method execution, based on which jvm can put forward the execution, whether return the control to the invoker or continue within the method. The frame’s creation and status moving forward, which consist of the execution, are totally decided by information of the corresponded method, stored in the method area, which is the program.
Collection of Frames
- private to each thread
- execution
- created when each thread is created
As mentioned above, it maintains all ever created and then discarded frames of a thread during execution.
Shared Data Area
- shared by all threads
- execution
- created at jvm start-up
All dynamically created data at runtime are stored at this area. It includes all class instances and arrays. This may correspond to the area in a conventional program where global variable and dynamically created data are stored.
Representation of Objects
- shared by all threads and accessed according to visibility of the type of each object
- execution
- created
- part of method area or shared data area
How does a real object is represented? Many abstract structural element may, via some way, have an access to this representation. Since each class has its own representation in jvm which is also an object, so in method area there also exist this kind of element. (correct me)
3. Data Structure Under the Hood
This section contains information that very likely is not very accurate and that is only based on my own knowledge. Please reference at your own risk.
pc
pc is a pointer which stored in register (logic register of jvm, or register on physical host machine). It may contain very little information. But what matters most is it must be very fast to access.
Method Area
Arrays, c-style structs, lists, tables (most likely an array of c-style structs), or cascaded tables.
Frames
local variables are stored in a table, and the status of the method execution is stored in a stack called operand stack. Executing instructions stored in method area may pop out from and/or push on stack the operands and/or results of operations.
Collection of Frames
Each collection is stored in a stack called JVM Stack. An invocation of a method push a newly created frame on the stack and completion of an invocation pops a frame out from the stack, and then the control returns to invoker’s frame. Each jvm thread has two kinds of stack: stack for java code and stack size for native code.
Shared Data Area
The shared data area is structured as a heap. GC consumes most of its time here.
Representation of Objects
Stored and organized on heap. Its internal structure may be c-style struct record.
Totally undefined which means it is completely subject to specific jvm implementation. Please skip this subsection.
But as I imagine, first get the representation of reference, and then the shared data area, and last the representation of objects.
As jvm spec stated, a reference is pointer to the address space that stores the address of the real object, which means it is similar to be of type pointer to a pointer.
4. More Under the Hood
This section contains information that very likely is not very accurate and that is only based on my own knowledge. Please reference at your own risk.
Heap and stack (and other data structures mentioned in this post) are not terms of jvm spec, they refer to underlying implementation of the data, or their counterpart terms in data structure theory. The purpose of introducing two concepts heap and stack and making the difference visible is that although they both can be dynamically allocated, workloads and policies of managing allocation and deallocation of these two kinds of data are quite different. Stack is quite manageable (which needs little workload and theoretically runs no risk of memory leak) and its size is easily inferred at compile time, while heap needs a quite complex way to manage (which needs so much workload that the runtime performance of the program based on it would be largely affected) and its size is most of time impossible to be inferred at compile time.
So below we divide memory as heap memory and non-heap memory, which is to follow Sun’s official document about JVM implementation.
Heap Memory
Non-heap Memory
- Java virtual machine stack
- native method stack (for native method frames, correct me)
- method area (logically belongs to, but adopt a quite different policy compared to runtime data area, so it is usually counted as non-heap memory), corresponding to Permanent Generation space of Sun’s implementation
- internal processes (threads scheduler or dispatcher) or optimization
Garbage Collection
Few parts of JVM’s memory is of fixed size at runtime, they may from time to time be expanded and/or compacted. This work is done by memory manager. And garbage collector is a type of memory manager. It is used to destroy “unreferenced” objects to free memory space.
Sun’s implementation of jvm use a strategy called generational GC (Garbage Collection). It divides memory into several generation, from young generation (eden space and survivor space, together sometimes are called new generation) , to tenured generation (or old generation), to permanent generation. When GC is performed in young generation , it is called a partial GC, when performed in old generation, it is called a full GC. Partial GC is much faster than full GC (why). Each generation is sometimes called a memory pool.
However, heap memory and non-heap memory don’t seem to have a clean alignment with generations mentioned above. But roughly heap memory aligns with eden space, survivor space and tenured space, and non-heap memory aligns with permanent generation. Tuning the size of different different generation space and their ratio has big impacts on the performance of GC when your program runs in some demanding environment, say within a hosted web server. And what makes the matter complex, almost every abstract structure element mentioned in previous section has corresponding option to get tuned.
GC is also can be configured to use different algorithms. But this is out of the scope of this post.
Tuning JVM
One of the purpose of writing this post is to let your better tune your jvm, that is, give you good conceptions of which part of jvm are you tuning when you adjust some of the jvm options. Troubleshooting and Diagnostic Guide is a good starting point to tuning your jvm. Below only Sun’s implementation is talked about.
Tuning Heap
Note that in Sun’s different official document there exist conflicts that permanent generation space sometimes is counted as heap memory and sometimes as non-heap memory, for which we mentioned above method area logically belongs to heap memory although we put it into the category of non-heap memory.
- -Xms[value] // initial size of the total heap, e.g., -Xms64m. This means a heap of this size will be occupied when the jvm is started up. If this amount of memory request couldn’t be meeted, the start-up would fail.
- -Xmx[value] // maximum size of the total heap, e.g., -Xmx1024m. When requested more memory usually during creating new class instances or arrays than maximum heap size, an OutOfMemoryError will be thrown
- -XX:MinHeapFreeRatio=minimum // the minimum proportion of free space to living objects (both of which make up the total heap), the lower limit of a range that each GC tries keep the proportion within
- -XX:MaxHeapFreeRatio=maximum // the maximum proportion of free space to living objects, the upper limit of a range that each GC tries keep the proportion within
- -XX:NewRatio=ratio // the proportion of new generation to old genertion,when heap grows or shrinks, jvm must recaculate the size of new and old generation
- -XX:NewSize=size // the minimum size of new generation
- -XX:MaxNewSize=size // the maximum size of new generation
- -XX:OldSize=size // the size of old generation
- -XX:SurvivorRatio=size // the proportion of survivor generation to eden generation
- -XX:PermSize=size // minimum size of permanent generation
- -XX:MaxPermSize=size // maximum size of permanent generation
Sun’s jvm has two equally sized survivor space, above tuning related to survivor is for each not for the two in total.
To make the matter clear, new generation and old generation definitions are redeclared here:
- new generation = eden space + survivor space
- old generation = tenured space
Tuning Others
- -XX:ThreadStackSize=512
- -Xss[value] // native method stack size, StackOverflowError will be thrown if this limit is exceeded
- -Xoss[value] // jvm stack size, StackOverflowError will be thrown if this limit is exceeded
5. Resources
- JVM SPEC 2nd edition, a must read.
- Using JConsole. aside from how to use it, it also contains much information about the structure of sun’s implementation of jvm.
- Troubleshooting and Diagnostic Guide. a good place to start investigating and experimenting.
- Open JDK. source codes are available for further investigating and experimenting.
- Questions about JVM internals, a discussion on bbs by non-experts, a good starting point.
- My another blog posts related (in Chinese)
- Tuning the Java Runtime System
- Tuning Java Virtual Machine, IBM’s guide in WebSphere manual.
- Categories of Java HotSpot VM Options
- JDK Tools and Utilities
Related Posts
Tags: data structure, gc, heap, Java, jdk, jvm, languages, memory, stack
About
