Garbage Collection and Classloading Java Garbage Collectors  Eden Space  Surviver Space  Tenured Gen  Perm Gen  Garbage Collection Notes Classloading  Classloader Family Tree  The Rules of Classloading  Custom Classloading  Breaking the Rules

Java Garbage Collectors 1/2 There are two basic types of Garbage Collector  Stop the world garbage-collectors All threads are suspended Garbage collection is performed All threads are re-started  Non-blocking garbage-collectors Execution is sometimes suspended for a short time before garbage collection is actually performed Java has 4 memory spaces or “heaps”  Objects are allocated, and promoted from one space to the other, the longer they live

Java Garbage Collectors 2/2 There are 3 different “Generations” in Java  Young Generation, divided into 3 spaces Eden Space Surviver From Space Surviver To Space  Tenured Generation For objects that are in current use  Perm Generation For VM objects and byte-code  java.lang.reflect objects  The VM's “Main” thread  The System Classloader

Eden Space 1/4 All Objects and primitives are allocated here Uses a “copy” garbage-collector  Copy is a stop-the-world collector  Two equal sized heaps  Allocate all data into the “active” heap  When the active heap is full, copy the live objects into the inactive heap  The inactive heap becomes the inactive heap Eden space is the smallest heap  This means that Eden space is frequently garbage collected

Eden Space 2/4 Advantages of a copy garbage collector  Very simple form of collection  Simple means it's fast  It has a “stack and compact” effect Data is always allocated on top of the heap When garbage collection occurs: all the live objects are compacted to the bottom of the heap Disadvantages  It's stop-the-world, nothing can execute while collection is happening  Uses 2 heaps, and so double the memory

Eden Space 3/4 (Copy Collection) ActiveActive ActiveActive Allocate Object ActiveActive ActiveActive Active Heap is Full ActiveActive Copy active objects Stop the world ActiveActive Swap Active Heap Restart the world

Eden Space 4/4 (Summary) Because Eden space is small, it is garbage collected often Eden space uses a stop the world garbage collector, but is very fast and so no effect is really visible on application performance Eden space may grow to accommodate larger or more objects  Both heaps will always be kept to the same size After garbage-collection, all remaining objects are moved to “Surviver Space”

Surviver Space 1/2 Contains objects that “survived” the Eden space  Objects that are not garbage-collected by the Eden space collector Surviver Space is treated the same as Eden space and is also a Copy based garbage-collector Surviver Space is larger than Eden space, and is tuned to flush out the short-lived objects that “escaped” collection in Eden space

Surviver Space 2/2 Surviver Space is divided into 2 parts  From Space – Treated much the same as Eden space  To Space – Where objects that survive Eden, and From Space are allocated to When the To space is filled with objects  The To space is garbage collected  The remaining objects are promoted to the “Tenured Gen”

Tenured Gen 1/3 When Surviver To Space is filled up, the live objects are promoted to Tenured Gen Tenured Gen is collected with a “mark-sweep- compact” Garbage Collector Most “long lived” objects exist in Tenured space Garbage Collection of Tenured space causes a very short pause of execution to determine the “root” objects Tenured space is Garbage Collected by default when it is 68% full

Tenured Gen 2/3 The “mark-sweep-compact” Garbage Collector only pauses execution to find the “root” objects  Root objects are those that are directly accessible by one or more currently executing thread The Garbage Collector traverses the object graph from the root objects while execution continues  Objects that are traversed over are marked as active  Objects that are not marked will be garbage collected The Garbage Collector doesn't move objects during execution, so “holes” are left in the heap

Tenured Gen 3/3 When no more objects can be allocated into the Tenured Gen it does a “stop the world” collection  All threads are suspended  The Garbage Collector runs  Remaining objects are reshuffled to be at the bottom of the heap  Threads are re-started Tenured Gen is the largest space  It takes the longest to Garbage Collect  It is to large for a “copy” Garbage Collector  The “mark-sweep-compact” collector operates early

Perm Gen Perm Gen is the “permanent” space in the VM  Used to store class byte-codes  The Virtual Machine's “Main” thread  Reflection objects You can generally assume that Perm Gen is never Garbage Collected  This causes problems with ClassLoader s, since each ClassLoader may load it's own copy of a single class  The most visible symptom is an OutOfMemoryException from application servers

Garbage Collection Notes Primitives in Java are not references Local variable “slots” are re-used by the compiler to reduce the number of variables Java 1.6 further optimizes Garbage Collection by having the compiler hint at when to Garbage Collect certain variables (scoping) The Garbage Collectors are very well tuned to most situations, but can be tuned using options The JConsole gives a good overview of memory usage and can also monitor a remote VM

Garbage Collection End Questions and Coffee Break

Classloading Classloader Family Tree The Rules of Classloading Custom Classloading Breaking the Rules

Classloader Family Tree 1/2 Bootstrap Classloader is used to load the System ClassLoader  SystemClassLoader is used to load all other classes All Classes have a parent ClassLoader  Any Class accessed by the Class is requested from it's parent ClassLoader  The parent ClassLoader always loaded the class Each ClassLoader also has a parent ClassLoader, this is normally the parent ClassLoader of the Class that instantiated the ClassLoader

ClassLoader Family Tree 2/2 ClassLoader s can access the Classes of their parent ClassLoader, but not of their child ClassLoader s  Think about the relationship between a normal Class and it's parent ClassLoader System ClassLoader Custom ClassLoader Custom Child ClassLoader

The Rules of ClassLoading 1/2 Override the findClass method rather than loadClass If overriding loadClass : call super.loadClass before attempting to resolve the Class yourself  This ensures that “ java.* ” packages cannot be overridden  Also helps conserves memory by making sure that a minimal set of Classes are loaded at any given time ClassLoaders should also implement the findResource method for getClass().getResource

The Rules of ClassLoading 2/2 Classes are always loaded using the loadClass method The default implementation resolves the class by: 1.Invoke ClassLoader.findLoadedClass(String) to check if the class has already been loaded. 2.Invoke the loadClass method on the parent class loader. If the parent is null the class loader built-in to the virtual machine is used, instead. 3.Invoke the findClass(String) method to find the class.

Custom ClassLoading 1/2 public class CustomClassLoader extends ClassLoader { private File directory;... protected Class findClass(String name) throws ClassNotFoundException { String classFileName = name.replace('.', '/') + “.class”; File classFile = new File(directory, classFileName); if(!classFile.exists() || !classFile.isFile()) { throw new ClassNotFoundException(); } else { try { byte[] bytecode = new byte[(int)classFile.length()]; FileInputStream fin = new FileInputStream(classFile); int length = fin.read(bytecode); fin.close(); return defineClass(name, bytecode, 0, length); } catch(IOException ioe) { throw new ClassNotFoundException(“Error loading class”, ioe); }

Custom ClassLoading 2/2 As you can see, custom ClassLoading is very simple  Caching of already loaded class is done in loadClass  Finding alternative Class's is done in loadClass  Verification of bytecodes is done in defineClass  All you do is load the bytecode into an array and pass it to defineClass To access a class loaded with a custom ClassLoader, use loadClass(fullClassName) and normal reflection to construct the object

Breaking the Rules Breaking the ClassLoading rules allows you to override standard and already-loaded Class's To break the rules, you will generally override the loadClass(String, boolean) method of ClassLoader  Allows you to override standard API's Don't call super.loadClass  Allows you to overwrite already loaded classes Don't make a call to findLoadedClass The old bytecode will exist so long as there is still a reference to an object of the old type

Questions If there are any?