Java - Garbage Collection

Generations

• Young Generation
• Eden Space
• Survivor Space
• S0
• S1
• Old Generation
• Tenured
• Permanent Generation

Minor GC

• Happens in Young Generation - When Eden fills up.
• Copies to empty Survivor space
• Promotion - Objects reaching certain age threshold are promoted to Old Generation. 

Major GC

• Happens  in Old Generation
• Happens Concurrently 

Full GC

• Both Minor GC and Major happen
• Major GC is triggered by Minor GC (promotion failure)

Collectors

Serial Collector

• Copying Collector
• Stop all application threads (STW)
• Perform collection using Single GC thread.

Parallel Collector

• Copying Collector
• Stop all application threads (STW)
• Perform collection using Multiple/Parallel GC threads.

Concurrent Collector

The concurrent collection cycle typically includes the following steps:

• Initial Mark - Stop all application threads (STW) and identify the set of objects reachable from roots, then resume all application threads
• Concurrent Mark - concurrently trace the reachable object graph, using one or more processors, while the application threads are executing
• Concurrent Mark - concurrently retrace sections of the object graph that were modified since the tracing in the previous step, using one processor
• Remark - Stop all application threads (STW) and retrace sections of the roots and object graph that may have been modified since they were last examined, then resume all application threads [ Multiple Threads ] 
• Concurrent Sweep - concurrently sweep up the unreachable objects to the free lists used for allocation, using one processor
• Concurrent Sweep - concurrently resize the heap and prepare the support data structures for the next collection cycle, using one processor
• Full Collection is STW collector
• Disadvantages
• CMS is non-compacting
• Extra processing required in Re-Mark phase
• Needs to use free-list to track free memory making a new allocation expensive
• Requires Larger heap size than other collectors
• Floating Garbage - More garbage can be created during concurrent sweep phase which will not be collected till next cycle
• Fragmentation

TRIGGER

• Attempts to start collection before Old Generation becomes full
• Uses time based heuristics [ how quickly Old Gen becomes full ] to determine when to  start next GC.
• Starts collection when occupancy increases the threshold Initiating Occupancy [ Configurable | Default 68% ] 

Concurrent Mode Failure
In normal operation, the concurrent collector does most of its tracing and sweeping work with the application threads still running, so only brief pauses are seen by the application threads. However, if the concurrent collector is unable to finish reclaiming the unreachable objects before the tenured generation fills up, or if an allocation cannot be satisfied with the available free space blocks in the tenured generation, then the application is paused and the collection is completed with all the application threads stopped. The inability to complete a collection concurrently is referred to as concurrent mode failure and indicates the need to adjust the concurrent collector parameters.


Excessive GC Time and OutOfMemoryError

The concurrent collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown

G1 Collector

• No physical separation between Young & Old Generations in the heap.
• Full memory is divided into regions.
• Each region is of size 1MB to 32MB
• Goal is to have 2048 regions in the heap.
• 
  

For Young Generation, you can use any one of the following:

• -XX:+UseSerialGC
• -XX:+UseParallelGC
• -XX:+UseParNewGC

For Old Generation, the available choices are:

• -XX:+UseParallelOldGC
• -XX:+UseConcMarkSweepGC

Collector Choices - http://www.fasterj.com/articles/oraclecollectors1.shtml

Young generation garbage collection algorithms

The (original) copying collector (Enabled by default). When this collector kicks in, all application threads are stopped, and the copying collection proceeds using one thread (which means only one CPU even if on a multi-CPU machine). This is known as a stop-the-world collection, because basically the JVM pauses everything else until the collection is completed.

The parallel copying collector (Enabled using -XX:+UseParNewGC). Like the original copying collector, this is a stop-the-world collector. However this collector parallelizes the copying collection over multiple threads, which is more efficient than the original single-thread copying collector for multi-CPU machines (though not for single-CPU machines). This algorithm potentially speeds up young generation collection by a factor equal to the number of CPUs available, when compared to the original singly-threaded copying collector.

The parallel scavenge collector (Enabled using -XX:UseParallelGC). This is like the previous parallel copying collector, but the algorithm is tuned for gigabyte heaps (over 10GB) on multi-CPU machines. This collection algorithm is designed to maximize throughput while minimizing pauses. It has an optional adaptive tuning policy which will automatically resize heap spaces. If you use this collector, you can only use the the original mark-sweep collector in the old generation (i.e. the newer old generation concurrent collector cannot work with this young generation collector).

From this information, it seems the main difference (apart from CMS cooperation) is that UseParallelGC supports ergonomics while UseParNewGC doesn't.


http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html


Using System.gc() does not guarantee a garbage collection

http://www.journaldev.com/4098/java-heap-memory-vs-stack-memory-difference

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

Reference counting collectors

Reference counting collectors keep track of how many references are pointing to each Java object. Once the count for an object becomes zero, the memory can be immediately reclaimed. 
Problem : If two objects reference each other and no live object refers to them, their memory will never be released

Tracing collectors

Tracing collectors are based on the assumption that all live objects can be found by iteratively tracing all references and subsequent references from an initial set of known to be live objects. The initial set of live objects (called root objects or justroots for short) are located by analyzing the registers, global fields, and stack frames at the moment when a garbage collection is triggered.

Tracing collector algorithms

• Copying Collectors
• Mark & Sweep Collectors ( CMS, G1, GenPair, DeterministicGC )

http://www.journaldev.com/2856/java-jvm-memory-model-and-garbage-collection-monitoring-tuning

http://www.cooljeff.co.uk/2009/11/01/garbage-collection-of-the-permanent-generation-permgen/

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

Java 8 Collectors

1. Serial
2. Parallel
3. Concurrent Mark & Sweep
4. Garbage First Collector (1MB)

Both the serial and parallel collectors cause a stop-the-world during the GC. so what's the difference between them? a serial collector is a default copying collector which uses only one GC thread for the GC operation, while a parallel collector uses multiple GC threads for the GC operation.
http://www.tikalk.com/java/garbage-collection-serial-vs-parallel-vs-concurrent-mark-sweep/#sthash.ndQrVUNs.dpuf

• what's the difference between the Parallel and the CMS collector?

the CMS performs the following steps (all made by only one GC thread):
- initial mark
- concurrent marking
- remark
- concurrent sweeping

there are two differences between a parallel and a CMS collectors:

1) the parallel uses multiple GC threads, while the CMS uses only one.
2) the parallel is a 'stop-the-world' collector, while the CMS stops the world only during the initial mark and remark phases.
during the concurrent marking and sweeping phases, the CMS thread runs along with the application's threads.

- See more at: http://www.tikalk.com/java/garbage-collection-serial-vs-parallel-vs-concurrent-mark-sweep/#sthash.ndQrVUNs.dpuf

Mark-and-sweep collectors (CMS, G1, GenPar, and DeterministicGC ..)
Implementations of mark-and-sweep
Parallel collectors / stop-the-world collectors  - all application threads are stopped until the entire garbage collection cycle is complete. Stopping all threads allows all resources to be efficiently used in parallel to finish the garbage collection through the mark and sweep phases. This leads to a very high level of efficiency, usually resulting in high scores on throughput benchmarks

Concurrent collectors
Concurrent means that some (or most) garbage collection work is performed concurrently with the running application threads

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

C4 - Continuous Concurrent Compacting Collector 

http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/

jvm-performance-optimization-part-3-garbage-collection

jvm-performance-optimization--part-4--c4-garbage-collection-for-low-latency-java-app

Garbage Collection Measurement

-verbose:gc

[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

GC = Minor Collection / FULL = Major Collection

325816K - Size of Live objects before Garbage Collection

 83372K - Size of Live objects After Garbage Collection

776768K - Committed size of heap - Amount of space usable by Java objects without requesting more memory form the Operating System.






-XX:+PrintGCDetails




[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]


196016K - Usage of heap before collection.
133633K - Usage of heap after collection.
261184K - Total size of heap.
0.0459067 secs - Time taken including overhead.

-XX:+PrintGCTimeStamps 

------------------------------

80.966: [Full GC 80.966: [CMS: 483K->481K(63872K), 0.0372414 secs] 14151K->481K(83008K), [CMS Perm : 83967K->5502K(83968K)], 0.0372776 secs] [Times: user=0.04 sys=0.00, real=0.03 secs] 

Java Reference Types

Strong Reference - objects that are reachable through any chain of strong references are not eligible for garbage collection 

Soft Reference - is less likely to be garbage collected at next GC. Soft references are cleared at the discretion of the garbage collector in response to memory demand. The virtual machine guarantees that all soft references to softly-reachable objects will have been cleared before it would ever throw an OutOfMemoryError. 

Weak Reference - An object that is identified as only weakly reachable will be collected at the next GC cycle. 

Phantom Reference -  In order to ensure that a reclaimable object remains so, the referent of a phantom reference may not be retrieved: The get method of a phantom reference always returns null. Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable.

ReferenceQueue - The Queue to which a Soft/Weak Reference is added once garbage collected. Reference.get() will return null.

remove() blocks till an element is available.

Use Case for ReferenceQueue - https://gist.github.com/UnquietCode/5717608

object = new Object();
ReferenceQueue<Object> rq = new ReferenceQueue<Object>();
WeakReference<Object> wr = new WeakReference<Object>(object, rq);
Reference<?> r = rq.remove();
if (r == wr) {
   // Object is no longer referenced.
}\

http://examples.javacodegeeks.com/core-java/lang/referencequeue/check-when-an-object-is-no-longer-referenced/


http://stackoverflow.com/questions/3646632/do-java-primitives-go-on-the-stack-or-the-heap

Resource Leak

http://stackoverflow.com/questions/26669437/reference-to-final-object-in-anonymous-class-constructor-a-leak