The purpose of the JVM is to load .class files and execute those .class files.
Lets say you have a A.java source file.
You can compile A.java with javac utility provided by JDK/JRE.
Now you get A.class (may be multiple .class files depending on your A.java inclusions). A.class is a bytecode version. Meaning it is not the final assembly instructions to be executed by the CPU. Still JVM process hasnt started.
JVM starts when you run your bytecode files (A.class)
When you run your A.class with java utility an instance of JVM is attached with the running process.
In that JVM instance your .class files(Along with standard Java classes like Object, System, String) are loaded into Class Loader module in JVM.
Loaded class files are then fed into the Execution engine module (Before it is fed into Execution engine and after its being processed from class loader module, the related data is stored at runtime data area). To execute the instruction in the bytecodes this module has to transact with OS via native method calls.
2. Link - First it verifies that wheather all the bytecodes are according to the JVM specification. Then in the prepare process, for class variables (static) only memory is allocated(Not for instance variables ). Finally in resolve phase symbolic references in your bytecodes are translated into actual references.
3. Initialize - All the static variables are initialized here.
Interpreter - just like a traditional interpreter it interprets the required instructions that are needed to be called to native methods . This is aided by JNI (Java Native method interface, and Native method libs like .dlls .so s)
JIT compiler and hotspot profier -
Garbage collector - If there is no references in stacks are pointed to objects in heap, those objects are removed from the heap by garbage collector. This is a memory optimization technique by JVM. This and this are good resources to refer.
Lets say you have a A.java source file.
You can compile A.java with javac utility provided by JDK/JRE.
Now you get A.class (may be multiple .class files depending on your A.java inclusions). A.class is a bytecode version. Meaning it is not the final assembly instructions to be executed by the CPU. Still JVM process hasnt started.
JVM starts when you run your bytecode files (A.class)
When you run your A.class with java utility an instance of JVM is attached with the running process.
In that JVM instance your .class files(Along with standard Java classes like Object, System, String) are loaded into Class Loader module in JVM.
Loaded class files are then fed into the Execution engine module (Before it is fed into Execution engine and after its being processed from class loader module, the related data is stored at runtime data area). To execute the instruction in the bytecodes this module has to transact with OS via native method calls.
Class Loader module
This does 3 things.
1. Load - This has sub class loading modules which loads system rt.jar files and additional .jar files and your .class files specified in CLASSPATH dir
2. Link - First it verifies that wheather all the bytecodes are according to the JVM specification. Then in the prepare process, for class variables (static) only memory is allocated(Not for instance variables ). Finally in resolve phase symbolic references in your bytecodes are translated into actual references.
3. Initialize - All the static variables are initialized here.
RT data areas
1. Method area - All the class level data is here (Reflection API, Static variables). This is also known as the permGen area. And By defualt 64 Megabytes are allocated to here. But as per you runtime requirements you can adjust this size allocated by the JVM instance. From Java 8 method area is moved to host operating system's memory area called metaspace.
2. Heap - This is where all the objects and its data are stored. Based on the runtime requirement you can adjust the heap size.
3.Program Counter (Register) - This is instruction list per thread. Meaning you will have n counters of programs for n threads.
4. Java stacks - Stack frames are stored in here per thread. For local methods.
Execution Engine
Interpreter - just like a traditional interpreter it interprets the required instructions that are needed to be called to native methods . This is aided by JNI (Java Native method interface, and Native method libs like .dlls .so s)
JIT compiler and hotspot profier -
Java code is normally distributed as bytecode, which is machine-independent pseudocode. (The same idea was previously used in UCSD-p system developed in the 70'ies.) The advantage of this is that the same application can be run in different processors and operating systems. In addition, the bytecode is often smaller than compiled application.
The disadvantage is that interpreting the code is slow compared to running compiled code. To solve this problem, JIT compiler was developed. JIT compiler compiles the code into machine code just before the code is executed. This speeds up the execution compared to interpreter, but additional time is spent for compiling every time the program is run. In addition, since JIT compiler must compile fast, it can not use complex optimization techniques that are used in static compilers.
Another approach is HotSpot compiling. It initially runs as interpreter, but then detects which routines are used most often and compiles only those. The advantage is that there is no initial delay due to the compiling. In addition, HotSpot compiler may do profiling during the execution and then issue stronger optimization for the most important routines. It may even gather information so that when you run the same application again and again, it will run faster and faster. More information about HotSpot compiling can be found from this article (tnx Pangea for the link).
Of course, instead of using JIT compiler, you could just use a static compiler to compile the bytecode for your machine. This allows full optimization and then you do not need to compile again every time you run the application. However, in phones and web pages, you often just execute the code (or applet) once, so JIT compiler may be a better choice. from stackoverflow
Garbage collector - If there is no references in stacks are pointed to objects in heap, those objects are removed from the heap by garbage collector. This is a memory optimization technique by JVM. This and this are good resources to refer.
