Garbage Collection and Classloading

1. 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

2. 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

3. 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

4. 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

5. 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

6. Eden Space 3/4 (Copy Collection) Allocate Object Allocate Object Active Heap is Full A c t i v e A c t i v e A c t i v e A c t i v e Copy active objects Swap Active Heap A c t i v e A c t i v e Stop the world Restart the world

7. 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”

8. 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

9. 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”

10. 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

11. 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

12. 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

13. 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 ClassLoaders, since each ClassLoader may load it's own copy of a single class • The most visible symptom is an OutOfMemoryException from application servers

14. 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

15. Questions and Coffee Break Garbage Collection End

16. Classloading • Classloader Family Tree • The Rules of Classloading • Custom Classloading • Breaking the Rules

17. 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

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

19. 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

20. The Rules of ClassLoading 2/2 • Classes are always loaded using the loadClass method • The default implementation resolves the class by: • Invoke ClassLoader.findLoadedClass(String) to check if the class has already been loaded. • 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. • Invoke the findClass(String) method to find the class.

21. 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 1/2

22. 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

23. 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

24. If there are any? Questions