Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

November Discount Launch 2022 – Top
We’re finally running a Black Friday launch. All Courses are 30% off until tomorrow:

>> GET ACCESS NOW

November Discount Launch 2022 – TEMP TOP (NPI)
We’re finally running a Black Friday launch. All Courses are 30% off until tomorrow:

>> GET ACCESS NOW

1. Introduction

Java 11 introduced a No-Op Garbage Collector called Epsilon, which promises the lowest GC overhead possible.

In this short tutorial, we'll explore how Epsilon works, and we'll mention the common use cases.

2. Quick Hands-On

Let's start with getting our hands dirty, and take Epsilon GC for a spin!

We'll first need an application, which creates garbage:

class MemoryPolluter {

    static final int MEGABYTE_IN_BYTES = 1024 * 1024;
    static final int ITERATION_COUNT = 1024 * 10;

    static void main(String[] args) {
        System.out.println("Starting pollution");

        for (int i = 0; i < ITERATION_COUNT; i++) {
            byte[] array = new byte[MEGABYTE_IN_BYTES];
        }

        System.out.println("Terminating");
    }
}

This code creates one-megabyte-arrays in a loop. Since we repeat the loop 10240 times, it means we allocate 10 gigabytes of memory, which is probably higher than the available maximum heap size.

We also provided some helper prints to see when the application terminates.

To enable Epsilon GC, we need to pass the following VM arguments:

-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

And when we run the application, we get the following error:

Starting pollution
Terminating due to java.lang.OutOfMemoryError: Java heap space

However, when we run the same application with the standard VM options, it completes fine:

Starting pollution
Terminating

Why did the first run fail? It seems like even the most basic garbage collectors could clean up the child's play that we just demonstrated!

So, let's take a look at the concepts behind Epsilon GC to understand what just happened.

3. How Epsilon GC Works

Epsilon is a no-op garbage collector.

JEP 318 explains that “[Epsilon] … handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down.

So, this explains why our application terminated with an OutOfMemoryError.

But, it raises the question: Why do we need to have a garbage collector, that doesn't collect any garbage?

There are some cases when we know that the available heap will be enough, so we don't want the JVM to use resources to run GC tasks.

Some examples of such cases (also from the related JEP):

  • Performance testing
  • Memory pressure testing
  • VM interface testing
  • Extremely short lived jobs
  • Last-drop latency improvements
  • Last-drop throughput improvements

4. Conclusion

In this short article, we learned about Epsilon, a no-op GC available in Java 11. We learned about the implications of using it and reviewed some cases where it may be handy.

As usual, the examples are available over on GitHub.

November Discount Launch 2022 – Bottom
We’re finally running a Black Friday launch. All Courses are 30% off until tomorrow:

>> GET ACCESS NOW

Generic footer banner
Comments are closed on this article!