Embed Size (px)
Citation preview
JAVA VIRTUAL MACHINETHE REAL THING: JAVA VIRTUAL MACHINE
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 directoryjre/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
