Imagine a software organization replaces its programmers with the ones who don’t know how to code; to calculate how long will it take for them to exhaust their funds and shut down. In this scenario, new revenue stops while pay to staff continues. In a similar manner, when one uses Epsilon garbage collector, introduced in Java 11, software application replaces its Garbage collector (GC) with Epsilon, which does not release memory; to calculate how long will it take for the JVM to exhaust all its memory and shut down.
The expected behavior of a GC is to allocate memory and then collect garbage (that is, release memory blocked by unused objects), so that developers can focus on other aspects of their applications. But GC behavior is un-deterministic– which means, you, as a developer can’t determine when GC cycles will start and introduce latency in your applications. This can be a major impediment in performance tuning especially when you are trying to investigate out the reason for instances of high latency in your system – whether it is your code – or the GC, which needs to be tuned.
Epsilon GC can help.
Epsilon is a no-operation GC – that doesn’t collect any garbage. It only handles allocation of memory. When the available Java heap exhausts, the JVM shuts down.
Here are a few scenarios where Epsilon is used.
Epsilon enables you to improve your applications by testing their performance. By comparing performance of your applications with Epsilon and other GCs, you can filter out GC-induced overheads from OS induced overheads – letting you choose the best GC.
Suppose you want to limit the memory usage of an application process. By using Epsilon, you can define the allocation limit, which fails JVM on heap exhaustion.You can stub the rest of processes and execute it using Epsilon with a memory allocation limit.
Since Epsilon doesn’t perform all the regular GC function of reclaiming memory, it has also proven useful in VM interface testing.
It is simple to use Epsilon. To evaluate Epsilon download JDK 11, released in Sep 2018.
Enable it at runtime using the options
followed by the application class name. Following is an example:
> java -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC MyApp
On initialization, Epsilon allocates memory in contiguous linear memory chunks, until your application completes its execution or runs out of heap memory. On running out of heap memory, JVM shuts down.
Epsilon must NOT be used in production. It is an experimental GC – to prevent it from being used in production unless explicitly enabled through JVM options, as it would be a disaster to use a GC that doesn’t reclaim memory. Epsilon is a powerful developer tool to fine tune application performance. Eventually, you’ll adopt another GC for your application in production.
Do you have alternatives to Epsilon? Yes, but it could be ambiguous, difficult or error prone.
You could configure existing GCs to never collect garbage, say, by setting very large young generation. But this could behave differently on different systems. You could modify existing GC to not collect garbage – but that could be against what they were designed for. Further improvements in existing GC – could reach overheads so low that Epsilon might not be required for latency or throughput parameters. But you could still use Epsilon for performance and memory testing.
Epsilon standardizes the process for application fine tuning. Several organizations have built custom JVMs – taking off garbage collection from it – so they could test their applications on multiple parameters like performance, memory, latency or throughput.
That’s not all. I think we have just scratched the surface and Epsilon can do much more. For example, it can help you create garbage free applications. One of the most popular ‘garbage free’ application is Log4j, a logging application by Apache. Give your imagination wings. Explore ways to make the best use of Epsilon.
– Mala Gupta