The code referenced in this article is sourced from sample code available on the Oracle blog regarding Epsilon GC.

In this article, we explore a particularly intriguing option in Java Garbage Collection (GC) known as Epsilon GC. This garbage collection algorithm is notable for its distinctive feature: it performs no garbage collection. The Epsilon garbage collector (GC) was included in JDK 11.

But what is the use of a garbage collector if its not collecting? (freeloader huh!!)

Nope, its actually quite useful, one such usecase as provided by Oracle blog, which I have slightly enhanced to be more helpful.

For further details, please refer to the original blog post:
https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector

The usecase: Epsilon GC is beneficial for developers who need to assess memory allocation for a particular segment of code without the aid of a profiling tool.

Primary Challenge Traditional garbage collectors can obscure accurate memory usage metrics by continuously clearing objects. This interference makes it difficult to ascertain the true memory consumption of your code.

Epsilon GC addresses this issue by acting as a non-collector. While not a garbage collection algorithm per se, it serves as a tool for understanding memory allocation by refraining from performing any garbage collection, thereby providing a clear picture of memory usage.

Note: It is important to be aware that since Epsilon GC does not reclaim memory, excessive allocation may lead to an OutOfMemoryError (OOM) in the JVM.

Below is the sample code that will be utilized to demonstrate the efficacy of Epsilon GC.:

public class EpsilonDemo {

    public static String formatSize(long v) {
        if (v < 1024) return v + " B";
        int z = (63 - Long.numberOfLeadingZeros(v)) / 10;
        return String.format("%.1f %sB", (double)v / (1L << (z*10)), " KMGTPE".charAt(z));
    }
    public static void printmem(){
        System.out.println("*** Free MEM = "+formatSize(Runtime.getRuntime().freeMemory()));
    }

    public static void main(String[] args) {

        final int MEGAABYTE = 1024 * 1024;
        final int ITERATIONS = 80;

        System.out.println("Starting allocations...");
        printmem();

        // allocate memory 1MB at a time
        for (int i = 0; i < ITERATIONS; i++) {
            var array = new byte[MEGAABYTE];
        }

        System.out.println("Completed successfully");
        printmem();
    }
}

Expectation:
The code allocates 80MB of byte type objects. We should be able to observe the same with the print statements when we execute the code.

Now to run the compiled version with/without EpsilonGC:

1. Running with G1GC:

java -Xms100m -Xmx100m -XX:+UseG1GC  EpsilonDemo
Starting allocations...
*** Free MEM = 102.2 MB
Completed successfully
*** Free MEM = 74.2 MB

So with G1GC we see an incorrect allocation picture of 28 MB utilization

1. Running with EpsilonGC:

java -Xms100m -Xmx100m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC EpsilonDemo
[0.004s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
Starting allocations...
*** Free MEM = 99.4 MB
Completed successfully
*** Free MEM = 18.7 MB 

Here you can clearly see 80.7 MB utilization

I hope this helps you see how EpsilonGC can be super handy for spotting memory usage patterns in your code. Cheers! 😊