JAVA VIRTUAL MACHINE
THE REAL THING: JAVA VIRTUAL MACHINE
http://frontech.com.tr
HIZIR SEFA İRKEN
SEFA.IRKEN@FRONTECH.COM.TR
THE REAL THING: JAVA VIRTUAL MACHINE
WHAT?
▸ VM is a layer of abstraction
▸ once only Java, but not anymore (after JDK 5)
▸ write once, run anywhere
▸ memory managed
▸ concurrent
▸ secure
THE REAL THING: JAVA VIRTUAL MACHINE
OUTSIDE
THE REAL THING: JAVA VIRTUAL MACHINE
INSIDE .CLASS FILE
JAVA VIRTUAL MACHINE
CLASS LOADER EXECUTION ENGINE
RUNTIME DATA AREAS
THE REAL THING: JAVA VIRTUAL MACHINE
INSIDE - KEY COMPONENTS
INSIDE
COMPONENTS OF JVM
1. bytecode verifier
2. class loader
3. execution engine
4. garbage collector
5. security manager
BYTECODE VERIFIER
BYTECODE VERIFIER
‣ first step in JVM is inspection
‣ checks for unusual code
‣ crucial for security
BYTECODE VERIFIER
WHAT BYTECODE CHECKED FOR
‣ variables are initialized before they are used
‣ method calls match the types of object references
‣ rules for accessing private data and methods are not
violated.
‣ local variable accesses fall within the runtime stack
‣ the runtime stack does not overflow
BYTECODE VERIFIER
HOW BYTECODE INSTRUCTIONS LOOK LIKE
CLASS LOADER
CLASS LOADER
‣ JVM doesn't need to know anything about runtime classes
‣ performs three main functions of JVM:
‣ loading
‣ linking
‣ initialization
‣ loads from anywhere
‣ every runtime has at least three class loaders
CLASS LOADER
THE LOADERS
‣ bootstrap class loader:

loads the system classes (typically from rt.jar)
‣ extension class loader:

loads “standart extensions” from the jre/lib/ext directory

jre/lib/endorsed will force override standard APIs
‣ system class loader:

loads the application classes from classpath.
EXECUTION ENGINE
EXECUTION ENGINE
‣ convert bytecode to machine code
‣ responsible for executing instructions contained in the
methods of loaded classes
‣ It has two parts:
‣ interpreter (ahead-of-time)
‣ JIT compiler aka just-in-time interpreter

JIT
JUST IN TIME - JIT
‣ advanced part of JVM
‣ starts after the program has started and compiles the code on the fly
‣ JIT has access to dynamic runtime information whereas a standard compiler
doesn't
‣ optimizes by compiling similar bytecodes at same time
‣ reduces overall execution time, improves performance

JIT
OPTIMIZATIONS
‣ inlining
‣ local optimizations
‣ control flow optimizations
‣ global optimizations
‣ native code generation
‣ reference: http://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/
com.ibm.java.lnx.70.doc/diag/understanding/jit_optimize.html
JIT
IN ACTION
GARBAGE COLLECTOR
GARBAGE COLLECTOR
‣ garbage collecting: freeing objects that are no longer referenced by the program
‣ in short checks periodically for not-needed objects
‣ no memory management needed from programmer, but be careful
‣ types:
‣ serial collector
‣ parallel collector
‣ parallel compacting collector
‣ concurrent mark-sweep (CMS) collector
‣ garbage-first (G1) garbage collector
GARBAGE COLLECTOR
G1 IS DESIGNED FOR
‣ can operate concurrently with applications threads like the CMS collector
‣ compact free space without lengthy GC induced pause times
‣ need more predictable GC pause durations
‣ do not want to sacrifice a lot of throughput performance
‣ do not want to require a much larger Java heap
HEAP
HEAP STRUCTURE
HEAP
AFTER YOUNG GENERATION COLLECTION
SECURITY MANAGER
SECURITY MANAGER
‣ not the security you think
‣ an object responsible for guarding security policies
‣ constantly monitors the code
‣ always consulted before any potentially dangerous operation
SECURITY MANAGER
EXAMPLE
SECURITY MANAGER
OUTPUT
OUT OF MEMORY!
BONUS TOPIC
OUT OF MEMORY
TYPES
‣ java heap space
‣ permgen space
‣ gc overhead limit exceeded
‣ unable to create new native thread
‣ and more..
OUT OF MEMORY
PERMGEN
‣ occurs when JVM wants to load new class definitions, but there is not enough
space in PermGen space
‣ you are trying to use more than you have - increase PermGen space
‣ possible class loader leak in your application or app server - needs code fix
OUT OF MEMORY
GC OVERHEAD LIMIT EXCEEDED
‣ overhead limit is the policy to allow jam to detect potential OOM conditions
beforehand
‣ caused by:
‣ too many full GC iterations
‣ too much time spent in GC
‣ fine tune jvm params and your GC, use GC logging
OUT OF MEMORY
UNABLE TO CREATE NEW NATIVE THREAD
‣ JVM ask for new thread from OS, OS can not allocate a new thread anymore
‣ check ulimit, this is a OS config
‣ use thread-pools if possible
‣ reduce heap space
‣ perform vertical scaling
OUT OF MEMORY
JAVA HEAP SPACE
‣ you ran out of allocated memory for your application
‣ memory can be increased by JVM params
‣ check your code for memory leaks and unused datasets
‣ diagnose problem with heap dump -jmap
REFERENCES
REFERENCES
‣ https://en.wikipedia.org/wiki/Memory_management#DYNAMIC
‣ https://en.wikipedia.org/wiki/Java_virtual_machine
‣ http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
‣ https://books.google.com.tr/books?id=K7i6AgAAQBAJ
‣ https://docs.oracle.com/javase/8/docs/technotes/guides/#javavm
‣ https://blog.frankel.ch/java-security-manager/#gsc.tab=0
‣ https://docs.oracle.com/javase/tutorial/essential/environment/security.html
‣ http://www.slideshare.net/surbhiiiii/javajava-virtual-machine
‣ http://www.slideshare.net/BaabtraMentoringPartner/java-virtual-machine-43141334
‣ http://www.slideshare.net/pritybhudolia/jvm-20513648
‣ http://www.slideshare.net/aparnachaudhary/understanding-jvm
‣ https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
‣ https://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf
‣ http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
‣ https://docs.oracle.com/javase/8/docs/technotes/guides/vm/
‣ https://docs.oracle.com/javase/8/docs/technotes/guides/vm/G1.html

The Real Thing: Java Virtual Machine

  • 1.
    JAVA VIRTUAL MACHINE THEREAL THING: JAVA VIRTUAL MACHINE
  • 2.
  • 3.
    THE REAL THING:JAVA VIRTUAL MACHINE WHAT? ▸ VM is a layer of abstraction ▸ once only Java, but not anymore (after JDK 5) ▸ write once, run anywhere ▸ memory managed ▸ concurrent ▸ secure
  • 4.
    THE REAL THING:JAVA VIRTUAL MACHINE OUTSIDE
  • 5.
    THE REAL THING:JAVA VIRTUAL MACHINE INSIDE .CLASS FILE JAVA VIRTUAL MACHINE CLASS LOADER EXECUTION ENGINE RUNTIME DATA AREAS
  • 6.
    THE REAL THING:JAVA VIRTUAL MACHINE INSIDE - KEY COMPONENTS
  • 7.
    INSIDE COMPONENTS OF JVM 1.bytecode verifier 2. class loader 3. execution engine 4. garbage collector 5. security manager
  • 8.
    BYTECODE VERIFIER BYTECODE VERIFIER ‣first step in JVM is inspection ‣ checks for unusual code ‣ crucial for security
  • 9.
    BYTECODE VERIFIER WHAT BYTECODECHECKED FOR ‣ variables are initialized before they are used ‣ method calls match the types of object references ‣ rules for accessing private data and methods are not violated. ‣ local variable accesses fall within the runtime stack ‣ the runtime stack does not overflow
  • 10.
    BYTECODE VERIFIER HOW BYTECODEINSTRUCTIONS LOOK LIKE
  • 11.
    CLASS LOADER CLASS LOADER ‣JVM doesn't need to know anything about runtime classes ‣ performs three main functions of JVM: ‣ loading ‣ linking ‣ initialization ‣ loads from anywhere ‣ every runtime has at least three class loaders
  • 12.
    CLASS LOADER THE LOADERS ‣bootstrap class loader:
 loads the system classes (typically from rt.jar) ‣ extension class loader:
 loads “standart extensions” from the jre/lib/ext directory
 jre/lib/endorsed will force override standard APIs ‣ system class loader:
 loads the application classes from classpath.
  • 13.
    EXECUTION ENGINE EXECUTION ENGINE ‣convert bytecode to machine code ‣ responsible for executing instructions contained in the methods of loaded classes ‣ It has two parts: ‣ interpreter (ahead-of-time) ‣ JIT compiler aka just-in-time interpreter

  • 14.
    JIT JUST IN TIME- JIT ‣ advanced part of JVM ‣ starts after the program has started and compiles the code on the fly ‣ JIT has access to dynamic runtime information whereas a standard compiler doesn't ‣ optimizes by compiling similar bytecodes at same time ‣ reduces overall execution time, improves performance

  • 15.
    JIT OPTIMIZATIONS ‣ inlining ‣ localoptimizations ‣ control flow optimizations ‣ global optimizations ‣ native code generation ‣ reference: http://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/ com.ibm.java.lnx.70.doc/diag/understanding/jit_optimize.html
  • 16.
  • 17.
    GARBAGE COLLECTOR GARBAGE COLLECTOR ‣garbage collecting: freeing objects that are no longer referenced by the program ‣ in short checks periodically for not-needed objects ‣ no memory management needed from programmer, but be careful ‣ types: ‣ serial collector ‣ parallel collector ‣ parallel compacting collector ‣ concurrent mark-sweep (CMS) collector ‣ garbage-first (G1) garbage collector
  • 18.
    GARBAGE COLLECTOR G1 ISDESIGNED FOR ‣ can operate concurrently with applications threads like the CMS collector ‣ compact free space without lengthy GC induced pause times ‣ need more predictable GC pause durations ‣ do not want to sacrifice a lot of throughput performance ‣ do not want to require a much larger Java heap
  • 19.
  • 20.
  • 21.
    SECURITY MANAGER SECURITY MANAGER ‣not the security you think ‣ an object responsible for guarding security policies ‣ constantly monitors the code ‣ always consulted before any potentially dangerous operation
  • 22.
  • 23.
  • 24.
  • 25.
    OUT OF MEMORY TYPES ‣java heap space ‣ permgen space ‣ gc overhead limit exceeded ‣ unable to create new native thread ‣ and more..
  • 26.
    OUT OF MEMORY PERMGEN ‣occurs when JVM wants to load new class definitions, but there is not enough space in PermGen space ‣ you are trying to use more than you have - increase PermGen space ‣ possible class loader leak in your application or app server - needs code fix
  • 27.
    OUT OF MEMORY GCOVERHEAD LIMIT EXCEEDED ‣ overhead limit is the policy to allow jam to detect potential OOM conditions beforehand ‣ caused by: ‣ too many full GC iterations ‣ too much time spent in GC ‣ fine tune jvm params and your GC, use GC logging
  • 28.
    OUT OF MEMORY UNABLETO CREATE NEW NATIVE THREAD ‣ JVM ask for new thread from OS, OS can not allocate a new thread anymore ‣ check ulimit, this is a OS config ‣ use thread-pools if possible ‣ reduce heap space ‣ perform vertical scaling
  • 29.
    OUT OF MEMORY JAVAHEAP SPACE ‣ you ran out of allocated memory for your application ‣ memory can be increased by JVM params ‣ check your code for memory leaks and unused datasets ‣ diagnose problem with heap dump -jmap
  • 30.
    REFERENCES REFERENCES ‣ https://en.wikipedia.org/wiki/Memory_management#DYNAMIC ‣ https://en.wikipedia.org/wiki/Java_virtual_machine ‣http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf ‣ https://books.google.com.tr/books?id=K7i6AgAAQBAJ ‣ https://docs.oracle.com/javase/8/docs/technotes/guides/#javavm ‣ https://blog.frankel.ch/java-security-manager/#gsc.tab=0 ‣ https://docs.oracle.com/javase/tutorial/essential/environment/security.html ‣ http://www.slideshare.net/surbhiiiii/javajava-virtual-machine ‣ http://www.slideshare.net/BaabtraMentoringPartner/java-virtual-machine-43141334 ‣ http://www.slideshare.net/pritybhudolia/jvm-20513648 ‣ http://www.slideshare.net/aparnachaudhary/understanding-jvm ‣ https://docs.oracle.com/javase/specs/jvms/se8/html/index.html ‣ https://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf ‣ http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html ‣ https://docs.oracle.com/javase/8/docs/technotes/guides/vm/ ‣ https://docs.oracle.com/javase/8/docs/technotes/guides/vm/G1.html