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)

Active

Active

Allocate Object

Active

Allocate Object

Active

Active Heap is Full

Active

Copy active objects

Stop the world

Active

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 ClassLoaders, 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

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

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/2public 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?