GC (Garbage Collection).

Permgen is Non-Heap memory., it contains completely the run time data 

Method Area: it is also Non-Heap area. And it is a part of Permgen it is used to store class structure.

Memory pool is belongs to Young gen, Old gen and Perm gen (it means it is included Heap & Non-Heap), it creates mostly immutable objects only (Immutable objects means the state of object is constant)

so this memory pool is created by JVM managers for the sake immutable objects.

Stack Memory :it contains the Method specific vales and all the short-lived references to other Objects in the heap.

Native Thread : Any Thread which is mapped to OS, that is called Native Thread.

GC : Collecting Unused Objects 

Ways to make an object eligible for Garbage Collector

If younger Generation is failed and not able to free the Memory to create new Objects it is Completly Developer Issue.

GC Mechanism :- 

• Half GC : Deallocate Memory from Younger Generation
• Full GC : Deallocate Memory from Both Generation

• Initial Memory(Total)
• Free Memory
• Max Memory
• Used Memory

                        Free Memory < Total Memory

                        Consumed memory = Initial Memory - Free Memory

                        Available Memory = Total Memory - Used Memory
Even though the programmer is not responsible for destroying useless objects but it is highly recommended to make an object unreachable(thus eligible for GC) if it is no longer required.

What are Garbage Collection Roots in Java?

GCs work on the concept of Garbage Collection Roots (GC Roots) to identify live and dead objects.  Examples of such Garbage Collection roots are:

• Classes loaded by system class loader (not custom class loaders)

• Live threads

• Local variables and parameters of the currently executing methods

• Local variables and parameters of JNI methods

• Global JNI reference

• Objects used as a monitor for synchronization

• Objects held from garbage collection by JVM for its purposes

How GC works ?

GC involves in 3 steps

1. Mark

2. Delete or Sweep

3. Compaction

so Phases of Garbage Collection in Java

• Mark the Objects as Live

• Sweep Dead Objects

• Compact Remaining Objects :- Means it is process of arranging in order( here GC is pausing)

Some Important terms :-

• Live Objects : The Objects which is referenced by another object
• Dead Objects : The Objects which is not referenced by another object and Unreachable
• Demon Thread : GC Process is carried out by Demon Thread
• System.GC : It is used to invoke the GC and on Invocation.
• The GC will run to reduce the Unused memory space. System.gc() is a Static method.

There are generally four ways to make an object eligible for garbage collection.

1. Nullifying the reference variable
2. Re-assigning the reference variable
3. An object created inside the method
4. Island of Isolation

GC Pattern :- 

1. Healthy saw-tooth pattern
2. Heavy caching pattern
3. Acute memory leak pattern
4. Consecutive Full GC pattern
5. Memory Leak Pattern

GC Types :-

1. Serial GC :  java -XX:+UseSerialGC -jar Application.java
2. Parallel GC : java -XX:+UseParallelGC -jar Application.java
3. CMS GC
4. G1 GC : java -XX:+UseG1GC -jar Application.java
5. Z GC : java -XX:+UseZGC Application.java

Serial GC :- This GC implementation freezes all application threads when it runs

Parallel GC :- This GC uses multiple threads for managing heap space, but it also freezes other application threads while performing GC. 

5. Z Garbage Collector (ZGC) is scalable, with low latency. It is a completely new GC, written from scratch. It can mark memory, copy and relocate it, all concurrently and it can work with heap memory, ranging from KBs to a large TB memory. As a concurrent garbage collector, ZGC guarantees not to exceed application latency by 10 milliseconds, even for bigger heap sizes. The ZGC was initially released as an experimental GC in Java 11 (Linux) and more changes are expected over time in JDK 11, 13, and 14.

The stop-the-world pauses are limited to root scanning in ZGC. It uses load barriers with colored pointers to perform concurrent operations when the threads are running and they are used to keep track of heap usage. Colored pointers are one of the core concepts of ZGC and it enables ZGC to find, mark, locate, and remap the objects. Compared to G1, ZGC has better ways to deal with very large object allocations which are highly performant when it comes to reclaiming memory and reallocating it and it is a single-generation GC.

ZGC divides memory into regions, also called ZPages. These ZPages can be dynamically created and destroyed and can also be dynamically sized. Unlike other GCs, the physical heap regions of ZGC can map into a bigger heap address space (which can include virtual memory) which can avoid memory fragmentation issues.

Troubleshoot performance issues

The first step is to determine whether the issue is actually garbage collection. If you determine that it is, select from the following list to troubleshoot the problem.

1. An out-of-memory exception is thrown
2. The process uses too much memory
3. The garbage collector does not reclaim objects fast enough
4. The managed heap is too fragmented
5. Garbage collection pauses are too long
6. Generation 0 is too big
7. CPU usage during a garbage collection is too high

Note :- If we increase GC Pause time. it is impact on Response time to getting more, and Throughput getting Down and automatically the Performance of the application will be decrease, and also getting high CPU Utilization , High Memory Utilization, 

eg : if GC Pause time is 9 sec and Response Time is 4 sec then total Transaction waited time is 13 sec which is not acceptable.

whenever GC is taking High pause time means the GC is taking more time to collect all the object and compact objects(means arranging the object in Order)

Note : If you try to decrease the Old Area size to Decrease the Full GC Execution time, OutofMemory may occur or the number of Full GC cycles may increase.

Alternatively  if you try to decrease the number of full GC by increasing the Old area size, the execution time will be increased.

Qus :- What did you do to improve the GC Mechanism?

Ans : The Major GC should be reduced or optimized because it will take application unresponsive duration.

Qus : What is the issue if Full GC Execution Time is High and Minor GC Execution Time Is also High ?

Ans : 

Garbage Collection and Performance | Microsoft Learn

1. Healthy saw-tooth pattern

Fig 1: Healthy saw-tooth GC pattern

You will see a beautiful saw-tooth GC pattern when an application is healthy, as shown in the above graph. Heap usage will keep rising; once a ‘Full GC’ event is triggered, heap usage will drop all the way to the bottom. 

In Fig 1, You can notice that when the heap usage reaches ~5.8GB, ‘Full GC’ event (red triangle) gets triggered. When the ‘Full GC’ event runs, memory utilization drops all the way to the bottom i.e., ~200MB. Please see the dotted black arrow line in the graph. It indicates that the application is in a healthy state & not suffering from any sort of memory problems. 

2. Heavy caching pattern

Fig 2: Heavy caching GC pattern

When an application is caching many objects in memory, ‘GC’ events wouldn’t be able to drop the heap usage all the way to the bottom of the graph (like you saw in the earlier ‘Healthy saw-tooth’ pattern). 

In Fig 2, you can notice that heap usage keeps growing. When it reaches around ~60GB, GC event (depicted as a small green square in the graph) gets triggered. However, these GC events aren’t able to drop the heap usage below ~38GB. Please refer to the dotted black arrow line in the graph. In contrast, in the earlier ‘Healthy saw-tooth pattern’, you can see that heap usage dropping all the way to the bottom ~200MB. When you see this sort of pattern (i.e., heap usage not dropping till all the way to the bottom), it indicates that the application is caching a lot of objects in memory. 

When you see this sort of pattern, you may want to investigate your application’s heap using heap dump analysis tools like yCrash, HeapHero, Eclipse MAT and figure out whether you need to cache these many objects in memory. Several times, you might uncover unnecessary objects to be cached in the memory.  

Here is the real-world GC log analysis report, which depicts this ‘Heavy caching’ pattern.

3. Acute memory leak pattern

Fig 3: Acute memory leak GC pattern

Several applications suffer from this ‘Acute memory leak pattern’. When an application suffers from this pattern, heap usage will climb up slowly, eventually resulting in OutOfMemoryError. 

In Fig 3, you can notice that ‘Full GC’ (red triangle) event gets triggered when heap usage reaches around ~43GB. In the graph, you can also observe that amount of heap that full GC events could recover starts to decline over a period of time, i.e., you can notice that

a. When the first Full GC event ran, heap usage dropped to 22GB 

b. When the second Full GC event ran, heap usage dropped only to 25GB

c. When the third Full GC event ran, heap usage dropped only to 26GB

d. When the final full GC event ran heap usage dropped only to 31GB

Please see the dotted black arrow line in the graph. You can notice the heap usage gradually climbing up. If this application runs for a prolonged period (days/weeks), it will experience OutOfMemoryError (please refer to Section #5 – ‘Memory Leak Pattern’). 

Here is the real-world GC log analysis report, which depicts this ‘Acute memory leak’ pattern.

4. Consecutive Full GC pattern

Fig 4: Consecutive Full GC pattern

When the application’s traffic volume increases more than JVM can handle, this Consecutive full GC pattern will become pervasive. 

In Fig 4, please refer to the black arrow mark in the graph. From 12:02pm to 12:30 pm on Oct’ 06, Full GCs (i.e., ‘red triangle’) are consecutively running; however, heap usage isn’t dropping during that time frame. It indicates that traffic volume spiked up in the application during that time frame, thus the application started to generate more objects, and Garbage Collection couldn’t keep up with the object creation rate. Thus, GC events started to run consecutively. Please note that when a GC event runs, it has two side effects: 

a. CPU consumption will go high (as GC does an enormous amount of computation).

b. Entire application will be paused; no customers will get response. 

Thus, during this time frame, 12:02pm to 12:30pm on Oct’ 06, since GC events are consecutively running, application’s CPU consumption would have been skyrocketing and customers wouldn’t be getting back any response. When this kind of pattern surfaces, you can resolve it using one of the solutions outlined in this post.

Here is the real-world GC log analysis report, which depicts this ‘Consecutive Full GC’ pattern.

5. Memory Leak Pattern

Fig 5: Memory Leak GC pattern

This is a ‘classic pattern’ that you will see whenever the application suffers from memory problems. In Fig 5, please observe the black arrow mark in the graph. You can notice that Full GC (i.e., ‘red triangle’) events are continuously running. This pattern is similar to the previous ‘Consecutive Full GC’ pattern, with one sharp difference. In the ‘Consecutive Full GC’ pattern, application would recover from repeated Full GC runs and return back to normal functioning state, once traffic volume dies down. However, if the application runs into a memory leak, it wouldn’t recover, even if traffic dies. The only way to recover the application is to restart the application. If the application is in this state, you can use tools like yCrash, HeapHero, Eclipse MAT to diagnose memory leak. Here is a more detailed post on how to diagnose Memory leak.

Here is the real-world GC log analysis report, which depicts this ‘Memory Leak’ pattern.

Ways for requesting JVM to run Garbage Collector

Once we make an object eligible for garbage collection, it may not destroy immediately by the garbage collector. Whenever JVM runs the Garbage Collector program, then only the object will be destroyed. But when JVM runs Garbage Collector, we can not expect.

We can also request JVM to run Garbage Collector. There are two ways to do it : 

Using System.gc() method: System class contain static method gc() for requesting JVM to run Garbage Collector.

Using Runtime.getRuntime().gc() method: Runtime class allows the application to interface with the JVM in which the application is running. Hence by using its gc() method, we can request JVM to run Garbage Collector.

There is no guarantee that any of the above two methods will run Garbage Collector.

The call System.gc() is effectively equivalent to the call : Runtime.getRuntime().gc()

Finalization

Just before destroying an object, Garbage Collector calls finalize() method on the object to perform cleanup activities. Once finalize() method completes, Garbage Collector destroys that object.

finalize() method is present in Object class with the following prototype.

protected void finalize() throws Throwable

Based on our requirement, we can override finalize() method for performing our cleanup activities like closing connection from the database. 

The finalize() method is called by Garbage Collector, not JVM. However, Garbage Collector is one of the modules of JVM.

Object class finalize() method has an empty implementation. Thus, it is recommended to override the finalize() method to dispose of system resources or perform other cleanups.

The finalize() method is never invoked more than once for any object.

If an uncaught exception is thrown by the finalize() method, the exception is ignored, and the finalization of that object terminates.

The advantages of Garbage Collection in Java are:

• It makes java memory-efficient because the garbage collector removes the unreferenced objects from heap memory.
• It is automatically done by the garbage collector(a part of JVM), so we don’t need extra effort.

Qus :- When the Object is getting destroyed ?

Ans : When ever the Object is not having Reference then the object is getting destroyed.

Qus : How do you the GC is Running ?

Ans :- by using any Jstack Command or JVisual VM, or JConsole or JProfiler or by using any APM tool we can monitor GC Metrics'.

Qus : Where we need to increase the Heap size ?

Ans : in Tomcat Catalina file

         in WebLogic    set Domain Env .cmd file

                Set WLS_MEM_ARGS_64Bit =    -XMS 512M and  -XMX 1024M

                Set WLS_MEM_ARGS_32Bit =    -XMS 512M and  -XMX 512M

Serial GC will work only standalone  applications and Desktop Applications.

If we use Distributed Application we will get High Performance issues.