Please enable JavaScript.

Coggle requires JavaScript to display documents.

Java Architecture (Runtime data areas (memory allocated to the JVM)…

- - - - loads the bytecode into memory
      - loaders
        
        Bootstrap class loader
        
        loads internal classes (from rt.jar)
        
        Extension class loader
        
        loads classes from jre/lib/ext folder
        
        Application class loader
        
        loads classes from classpath (specified in environment variable)
    - - has 3 phases
        
        1) Verify
        
        checks if the byte code is ok with the JVM specification
        
        2) Prepare
        
        memory is allocated only for static variables and they are set to default values (false for boolean etc)
        
        3) Resolve
        
        all the symbolic references inside the current class are resolved
        to actual references
      - these 3 phases may overlap or be executed in parallel
    - - here static initializers of your class are run (and e.g. actual boolean values are set to that memory area)
- - - - After data area is loaded with the instruction to be executed interpreter interprets the current instruction that is at that moment a bytecode, looks at it, finds out what native operation has to be done and executes that native operation. This is done by using Native Method Interface which interfaces the native method libraries that are present in the JVM.
      - In jre bin folder there are a lot of .dll files if you are on Windows - those are platform-specific native libraries used by the Execution Engine. You could see .so files on Linux.
    - - If we have a set of instructions that are executed repeatedly, those will not be interpreted again and again, instead JIT compiles them on the fly and keeps machine code corresponding to these instructions ready for execution so there is no longer interpretation involved here.
      - improves the performance of Java applications at run time, not compile time.
      - To improve performance, JIT compilers interact with the JVM at run time and compile appropriate bytecode sequences into native machine code. When using a JIT compiler, the hardware can execute the native code, as opposed to having the JVM interpret the same sequence of bytecode repeatedly and incurring the penalty of a relatively lengthy translation process. The JIT compiler performs certain optimizations when compiling the bytecode to native code. Some of the common optimizations performed by JIT compilers are data-analysis, translation from stack operations to register operations, reduction of memory accesses by register allocation, elimination of common sub-expressions etc.
      - types
        
        For long-running applications such as server-side enterprise Java applications, a client-side compiler might not be enough. A server-side compiler like C2 could be used instead.
        
        A well-known optimizing compiler is C1, the compiler that is enabled through the -client JVM startup option. As its startup name suggests, C1 is a client-side compiler.
    - - keeps an eye on the bytecode running and gathers statistics about it so JIT can use them and make Java faster.
- - - - Garbage collection is unpredictible, we can't force it's execution and we don't know how long will it take so we can't predict when our operation is executed.
    - - Java offers only ways to communicate with underlying OS that are shared across all the systems; trying to invoke more sophisticated system functions will be hacky. Use C and C++ instead.