If you ever wanted to watch memory allocation behave like a toddler in a candy store then Epsilon GC is your new best friend. This no op garbage collector does not reclaim memory and it keeps allocating until the heap runs out. That makes it a great baseline for GC benchmarking and Java performance investigations when you want to measure pure allocation cost without the background noise of pausetime reclamation.

Why Epsilon GC matters for benchmarking

Epsilon GC is a no op GC that performs no garbage reclamation. In practice that means your application will allocate normally and the JVM will not try to free anything. The JVM continues until an OutOfMemoryError stops the party. That behavior is useful when you want a clean baseline to profile allocation hotspots and compare raw allocation overhead between runtimes or collectors.

Set up a stress workload

Build a simple Java program that allocates objects quickly. A tight loop that creates large arrays or many short lived objects will do. The goal is steady allocation pressure so the lack of GC activity makes a measurable difference in timings.

Example pattern

for (int i = 0; i < 10_000_000; i++) {
    byte[] b = new byte[1024];
    // keep a subset referenced sometimes to vary lifetime
    if (i % 1000 == 0) retained.add(b);
}

Start OpenJDK with Epsilon

Launch the JVM with the Epsilon option and a fixed heap. For example run your jar like this and capture logs.

java -XX:+UseEpsilonGC -Xmx1g -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -jar yourapp.jar > out.log 2>&1

The important parts are the UseEpsilon flag and the heap cap. You can include GC diagnostics to record heap state at failure and to help with postmortem analysis.

What to watch for

• Steady allocation with no GC pauses until an OutOfMemoryError occurs
• Heap dumps created by HeapDumpOnOutOfMemoryError for post run analysis
• Application timings that reflect raw allocation cost rather than reclamation overhead

How to interpret results

If your goal is micro benchmarking or to measure allocator efficiency then Epsilon can reduce noise from background GC threads. If your aim is production reliability then do not use Epsilon. No cleanup means no long lived service.

When Epsilon is useful

• Baseline allocation cost for Java performance tuning
• GC benchmarking and regression testing of allocation paths
• Spotting allocation hotspots without pauses getting in the way

When Epsilon is not useful

• Any production workload that needs continuous uptime
• Memory constrained environments where reclaim is required

Practical checklist

• Make a repeatable allocation workload
• Run with -XX:+UseEpsilonGC and a fixed -Xmx value
• Enable GC diagnostics and heap dump on OOM
• Compare timings against other collectors to see the real impact

In short, Epsilon GC is a brutal but useful tool. Use it for controlled experiments in OpenJDK when you want a clean measurement of allocation behavior and Java performance. Do not use it if you want a system that survives past the first memory cliff.