<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[Stories by Arvind Vignesh on Medium]]></title>
        <description><![CDATA[Stories by Arvind Vignesh on Medium]]></description>
        <link>https://medium.com/@ArvindVignesh?source=rss-1ad755a31ea6------2</link>
        <image>
            <url>https://cdn-images-1.medium.com/fit/c/150/150/1*jP3sqQsyFTSMXWB8yrNXQw.jpeg</url>
            <title>Stories by Arvind Vignesh on Medium</title>
            <link>https://medium.com/@ArvindVignesh?source=rss-1ad755a31ea6------2</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Tue, 19 May 2026 12:49:31 GMT</lastBuildDate>
        <atom:link href="https://medium.com/@ArvindVignesh/feed" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com" rel="hub"/>
        <item>
            <title><![CDATA[Garbage Collection In Java]]></title>
            <link>https://medium.com/@ArvindVignesh/garbage-collection-in-java-b90a7f4b3ac7?source=rss-1ad755a31ea6------2</link>
            <guid isPermaLink="false">https://medium.com/p/b90a7f4b3ac7</guid>
            <category><![CDATA[java]]></category>
            <category><![CDATA[java-garbage-collection]]></category>
            <category><![CDATA[jvm]]></category>
            <category><![CDATA[java-memory-management]]></category>
            <dc:creator><![CDATA[Arvind Vignesh]]></dc:creator>
            <pubDate>Sun, 26 May 2024 07:23:07 GMT</pubDate>
            <atom:updated>2025-01-17T16:48:57.336Z</atom:updated>
            <content:encoded><![CDATA[<h4>A basic rundown on how garbage collection takes place in Java</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*8ZKpEOPbbNTgQ8WQ" /><figcaption>Photo by <a href="https://unsplash.com/@neonbrand?utm_source=medium&amp;utm_medium=referral">Kenny Eliason</a> on <a href="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>What is Garbage Collection?</h3><p>Declaring variables is a part and parcel of life as a programmer. It is encouraged for programmers to use variables in their code as they not only facilitate reusability, they also contribute a great deal in enhancing the readability of your code, which in turn enhances the maintainability of the code. It is also not exactly a secret that these variables being declared take up space, and also have a certain scope associated with them. So for optimized memory management it makes sense for the JVM to clear or destroy these objects once they are not needed. This process of clearing the “unwanted” variables is known as Garbage Collection(GC).</p><h4>Garbage Collection in JAVA</h4><p>Garbage collection in languages like C,C++ falls on the responsibility of the application developer as you have explicit tools to manually take out the trash in those languages. In Java on the other hand, the JVM does Garbage Collection automatically. JVM goes through a set of processes that determine when and where to trigger GC in the heap memory. As a Java developer, it’s imperative understanding the basics of GC and the sections of heap memory which will greatly help us in building memory efficient Java applications.</p><h4>Phases involved in Garbage collection</h4><p>Java garbage collection is usually done in two phases. The <em>mark </em>phase and the <em>sweep </em>phase.</p><p><strong>Mark Phase: </strong>In mark<strong> </strong>phase the objects are classified in two ways, referenced and unreferenced. Referenced objects are the ones that are still in use and which are not out of scope. Unreferenced are the ones that are not needed by the application anymore. The unreferenced objects are “marked” for garbage collection.</p><p><strong>Sweep Phase</strong>: In sweep phase the objects that are “marked” are deleted/cleared. Additionally, sometimes the heap also initiates something called <em>Memory compaction</em> <a href="https://en.wikipedia.org/wiki/Mark%E2%80%93compact_algorithm"><em>(Mark-compact-algorithm)</em></a> which reallocates the memory so that the remaining objects are still in contiguous memory. This process makes it so that the JVM can allocate the memory sequentially to the newly created objects. The details of the memory compaction process is out of the scope of this article so we will skip over that.</p><p>To maintain efficient garbage collection there are some garbage collection strategies that the JVM follows. The most common strategy is the generational garbage collection strategy.</p><h4>Generational Garbage Collection Strategy</h4><p>We will explore the generational garbage collection strategy here as it is the most common form of garbage collection used. Generational garbage collection is preferred for two main reasons.</p><ol><li>The process of marking, sweeping and then compacting becomes extremely inefficient as more and more objects are getting allocated in the memory. This further increases the time to mark, sweep and compact which will lead to extremely large GC times.</li><li>Analysis have proved that most objects in Java applications are short lived.</li></ol><p>For the above reasons mentioned, to make the process of GC more efficient the heap memory of Java is broken down into segments or Generations.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/641/1*p8fSpdVNFOkIzwi14y3DTQ.png" /><figcaption>Heap Space Segments</figcaption></figure><p><strong>Young Generation:</strong></p><p>The Young Generation is divided into three regions. The Eden Space, Survivor space zero (S0) and Survivor Space one (S1). Let us discuss the process of Garage collection from the point of application boot up.</p><p>At the start, all the newly created objects are filled in the Eden Space. Both the survivor spaces (S0 and S1) will be empty. As the Eden space fills up, a minor garbage collection cycle is triggered. All the unreferenced objects in the Eden Space are deleted and all the referenced objects are moved to S0. This is gc(0).In the next consequent Garbage collection cycle, all the referenced objects from the Eden space and the S0 space are moved into S1. After this all the unreferenced objects are deleted. The Object allocation after gc(1) will look something similar to this.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/850/1*xTk2ImBJAFaLFOVnUEVQag.png" /><figcaption>Objects before and after gc(1)</figcaption></figure><p>We can observe from the above image that after every gc cycle the age of the objects are incremented by 1. After the age reaches a certain threshold, the objects are moved to the next section of heap memory. We also need to know that all minor GCs are <em>Stop the world</em> events. This means that the application threads are stopped until the GC is completed. Typically minor GCs take less time when compared to Major GCs.</p><p><strong>Old Generation</strong></p><p>Eventually when the object’s age reaches a certain threshold, they are moved from the young generation to the old generation. In due course, the Old generation also fills up. When the old generation fills up and is needed to be cleaned, a major GC is triggered.</p><p><strong>Differences between Major GC and a Minor GC</strong></p><p>One of the major differences between a Minor GC and a Major GC is the time it takes to complete a Minor and a Major GC. While Major GCs are also stop the world events like minor GCs the amount of time that takes to complete a Major GC is so much more than a minor GC as it involves all live objects. The amount of time it takes to complete a Major GC also increases linearly with the major GC space as more space means more time for memory compaction. This means that in applications that prioritizes response time, we would need to maintain a low frequency when it comes to Major GCs . It is also worth noting that the length of the <em>stop the world</em> events in a major GC depends on the type of GC being used.</p><p><strong>Full GC</strong></p><p>A Full GC in Java Garbage collection is when both young generation and old generation GCs are triggered. A full garbage collection takes so much more time than a minor or a major GC. There can be multiple reasons as to why full GC happens. A couple of them include :</p><ol><li>Heap Space filling up: A Full GC could occur before all Java heap memory has been exhausted due to the necessity of finding a contiguous set of regions for them.</li><li>Change in region sizes: When there is a change in region sizes (young or old) depending on the demand of memory, normally region resizing is initiated by a full GC.</li></ol><h4>Metaspace</h4><p>There is an additional segment of memory which used to be a part of the heap memory and was also included in a full garbage collection. This segment of memory was called Permanent generation. In Java 8 permanent generation was changed to Metaspace and was moved away from the heap memory. The primary reason for metaspace existence is to store class metadata. It has the capability to auto increase if the class needs more space to load and store metadata.</p><p>Understanding Java Garbage collections is very important in making your java applications more efficient and also troubleshooting and fixing potential memory leaks in the system.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=b90a7f4b3ac7" width="1" height="1" alt="">]]></content:encoded>
        </item>
    </channel>
</rss>