Garbage Collection and Classloading Java Garbage Collectors Eden Space Surviver Space Tenured Gen...
-
Upload
franklin-blair -
Category
Documents
-
view
233 -
download
0
Transcript of Garbage Collection and Classloading Java Garbage Collectors Eden Space Surviver Space Tenured Gen...
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?