Java garbage collection is one of the perks of being a Java developer. Always enabled and working for us in the background. However there are some interesting cases where you want to disable Java garbage collection! Get introduced to the Epsilon no-op garbage collector.
Epsilon nop-op Garbage Collector | What is it?
Java 11 introduced an experimental GC called the Epsilon no-op GC. There are many different GC’s to chose from but Epsilon is the most different for sure. Epsilon is the lowest overhead Java GC available. This means it doesn’t degrade performance by introducing random GC pauses while our application is executing. Basically it’s a GC that does no actual garbage collection … weird, huh?
Epsilon however continues to allocate memory until there is no room left on the heap. At that point, the JVM shuts down due to out of memory errors. You enable it via the java command option –XX:+UseEpsilonGC
Where to Disable Java Garbage Collection?
It’s definitely not meant for production but it can be great to use in a testing environment. Of course, I’m not suggesting to use it for all your tests because that would not be practical. You would eventually run out of memory for the wrong reasons.
What I am suggesting is that there are some specific types of tests which can benefit from the absence of the garbage collection process.
When running tests, It can be frustrating when you’re trying to benchmark application performance under some purposely induced stress/load. These tests are executed over a short run and your results may be off due to one or more GC cycles kicking in during your test. The after math may show that a lot of time and resources were spent on the garbage collection process.
What to do then when you don’t want GC to stop you in the middle of a stress test? This and some other test use cases are where we can improve Java testing efficiency by disabling the Java GC.
When to Disable Java Garbage Collection?
Here are some testing scenarios when it could be advantageous to disable Java garbage collection.
- Performance testing and micro bench-marking algorithms
- Running regression tests to identity memory leaks
- Testing third party libraries, Java API’s and your own as well for memory allocations under usage.
- Simulating OOM errors in a microservices architecture where containers just die. Does the cluster recover as expected on an application level and orchestration level?
By turning off Java GC for these test cases, we would be able to get accurate results and side step unpredictable pauses.
Java Epsilon no-op GC in Action
The following example simulates a load test by creating many new byte[] Objects until an entire GigaByte’s worth is populated into the ArrayList.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
org.example; import java.util.*; public class App { public static void main( String[] args ) { System.out.println( "Starting ..." ); final int GIGA_BYTE = 1 * 1024 * 1024; List<byte[]> buffer = new ArrayList<>(); for (int i=0 ; i < GIGA_BYTE; i++){ buffer.add(new byte[1024]); byte[] arr = new byte[1024]; // unreferenced for GC to pick up! } System.out.println( "Finished." ); } } |
Once the above code is packaged into a jar file, we can execute the jar command from the CLI with garbage collection logs enabled to see what is going on. I am capping the minimum and maximum Java heap space size to 1 GigaByte on the CLI.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
mvpjava@jetbrains:~/IdeaProjects/java-eclipse-gc$ time java -cp target/java-eclipse-gc-1.0-SNAPSHOT.jar -Xms1G -Xmx1G -verbose:gc -Xlog:gc org.example.App [0.014s][info][gc] Using G1 Starting ... [0.221s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 51M->25M(1024M) 21.327ms [0.260s][info][gc] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 69M->47M(1024M) 24.553ms [0.290s][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 91M->69M(1024M) 15.309ms [0.337s][info][gc] GC(3) Pause Young (Normal) (G1 Evacuation Pause) 113M->91M(1024M) 41.654ms [0.368s][info][gc] GC(4) Pause Young (Normal) (G1 Evacuation Pause) 136M->115M(1024M) 23.952ms [0.398s][info][gc] GC(5) Pause Young (Normal) (G1 Evacuation Pause) 159M->137M(1024M) 17.227ms [0.431s][info][gc] GC(6) Pause Young (Normal) (G1 Evacuation Pause) 181M->160M(1024M) 25.296ms [0.464s][info][gc] GC(7) Pause Young (Normal) (G1 Evacuation Pause) 205M->183M(1024M) 19.341ms [0.506s][info][gc] GC(8) Pause Young (Normal) (G1 Evacuation Pause) 234M->209M(1024M) 33.508ms [0.565s][info][gc] GC(9) Pause Young (Normal) (G1 Evacuation Pause) 268M->239M(1024M) 48.746ms [0.613s][info][gc] GC(10) Pause Young (Normal) (G1 Evacuation Pause) 308M->275M(1024M) 36.354ms [0.673s][info][gc] GC(11) Pause Young (Normal) (G1 Evacuation Pause) 352M->314M(1024M) 42.177ms [0.745s][info][gc] GC(12) Pause Young (Normal) (G1 Evacuation Pause) 403M->359M(1024M) 52.166ms [0.841s][info][gc] GC(13) Pause Young (Normal) (G1 Evacuation Pause) 464M->413M(1024M) 72.291ms [0.915s][info][gc] GC(14) Pause Young (Normal) (G1 Evacuation Pause) 526M->470M(1024M) 51.149ms [1.008s][info][gc] GC(15) Pause Young (Normal) (G1 Evacuation Pause) 602M->536M(1024M) 63.992ms [1.049s][info][gc] GC(16) Pause Young (Concurrent Start) (G1 Humongous Allocation) 565M->552M(1024M) 27.460ms [1.050s][info][gc] GC(17) Concurrent Cycle [1.145s][info][gc] GC(18) Pause Young (Normal) (G1 Evacuation Pause) 693M->624M(1024M) 63.881ms [1.233s][info][gc] GC(19) Pause Young (Normal) (G1 Evacuation Pause) 744M->684M(1024M) 52.254ms [1.340s][info][gc] GC(20) Pause Young (Normal) (G1 Evacuation Pause) 784M->735M(1024M) 71.133ms [1.412s][info][gc] GC(21) Pause Young (Normal) (G1 Evacuation Pause) 816M->775M(1024M) 43.768ms [1.489s][info][gc] GC(22) Pause Young (Normal) (G1 Evacuation Pause) 840M->808M(1024M) 41.376ms [1.574s][info][gc] GC(23) Pause Young (Normal) (G1 Evacuation Pause) 864M->839M(1024M) 38.160ms [1.629s][info][gc] GC(24) Pause Young (Normal) (G1 Evacuation Pause) 882M->861M(1024M) 32.257ms [1.668s][info][gc] GC(25) Pause Young (Normal) (G1 Evacuation Pause) 905M->883M(1024M) 29.397ms [1.698s][info][gc] GC(26) Pause Young (Normal) (G1 Evacuation Pause) 927M->906M(1024M) 21.510ms [1.729s][info][gc] GC(17) Pause Remark 919M->915M(1024M) 24.368ms [1.770s][info][gc] GC(27) Pause Young (Normal) (G1 Evacuation Pause) 946M->924M(1024M) 25.487ms [1.812s][info][gc] GC(28) Pause Young (Normal) (G1 Evacuation Pause) 968M->947M(1024M) 26.400ms [1.854s][info][gc] GC(29) Pause Young (Normal) (G1 Evacuation Pause) 991M->969M(1024M) 24.987ms [1.923s][info][gc] GC(30) To-space exhausted [1.923s][info][gc] GC(30) Pause Young (Normal) (G1 Evacuation Pause) 1013M->1013M(1024M) 51.053ms [1.956s][info][gc] GC(31) To-space exhausted [1.956s][info][gc] GC(31) Pause Young (Normal) (G1 Evacuation Pause) 1024M->1024M(1024M) 24.208ms [2.686s][info][gc] GC(32) Pause Full (G1 Evacuation Pause) 1024M->975M(1024M) 730.149ms [2.687s][info][gc] GC(17) Concurrent Cycle 1637.000ms [2.714s][info][gc] GC(33) To-space exhausted [2.715s][info][gc] GC(33) Pause Young (Normal) (G1 Evacuation Pause) 1021M->1021M(1024M) 19.691ms [3.018s][info][gc] GC(34) Pause Full (G1 Evacuation Pause) 1021M->998M(1024M) 302.774ms [3.043s][info][gc] GC(35) To-space exhausted [3.044s][info][gc] GC(35) Pause Young (Concurrent Start) (G1 Evacuation Pause) 1021M->1021M(1024M) 21.871ms [3.044s][info][gc] GC(37) Concurrent Cycle [3.292s][info][gc] GC(36) Pause Full (G1 Evacuation Pause) 1021M->1010M(1024M) 248.330ms [3.293s][info][gc] GC(37) Concurrent Cycle 248.724ms [3.301s][info][gc] GC(38) To-space exhausted [3.301s][info][gc] GC(38) Pause Young (Normal) (G1 Evacuation Pause) 1023M->1023M(1024M) 5.739ms [3.575s][info][gc] GC(39) Pause Full (G1 Evacuation Pause) 1023M->1016M(1024M) 274.136ms [3.584s][info][gc] GC(40) To-space exhausted [3.584s][info][gc] GC(40) Pause Young (Concurrent Start) (G1 Evacuation Pause) 1022M->1022M(1024M) 6.856ms [3.584s][info][gc] GC(42) Concurrent Cycle [3.857s][info][gc] GC(41) Pause Full (G1 Evacuation Pause) 1022M->1019M(1024M) 272.857ms [3.858s][info][gc] GC(42) Concurrent Cycle 273.275ms [3.863s][info][gc] GC(43) To-space exhausted [3.864s][info][gc] GC(43) Pause Young (Normal) (G1 Evacuation Pause) 1022M->1022M(1024M) 5.320ms [4.122s][info][gc] GC(44) Pause Full (G1 Evacuation Pause) 1022M->1021M(1024M) 258.562ms [4.124s][info][gc] GC(45) To-space exhausted [4.124s][info][gc] GC(45) Pause Young (Concurrent Start) (G1 Evacuation Pause) 1022M->1022M(1024M) 1.281ms [4.125s][info][gc] GC(47) Concurrent Cycle [4.380s][info][gc] GC(46) Pause Full (G1 Evacuation Pause) 1022M->1021M(1024M) 255.256ms [4.383s][info][gc] GC(48) To-space exhausted [4.383s][info][gc] GC(48) Pause Young (Normal) (G1 Evacuation Pause) 1022M->1022M(1024M) 2.924ms [4.797s][info][gc] GC(49) Pause Full (G1 Evacuation Pause) 1022M->1022M(1024M) 413.672ms [4.797s][info][gc] GC(47) Concurrent Cycle 672.647ms [4.800s][info][gc] GC(50) To-space exhausted [4.800s][info][gc] GC(50) Pause Young (Normal) (G1 Evacuation Pause) 1023M->1023M(1024M) 2.162ms [5.065s][info][gc] GC(51) Pause Full (G1 Evacuation Pause) 1023M->1022M(1024M) 264.584ms [5.296s][info][gc] GC(52) Pause Full (G1 Evacuation Pause) 1022M->1022M(1024M) 230.614ms [5.297s][info][gc] GC(53) Pause Young (Concurrent Start) (G1 Evacuation Pause) 1022M->1022M(1024M) 0.434ms [5.297s][info][gc] GC(55) Concurrent Cycle [5.551s][info][gc] GC(54) Pause Full (G1 Evacuation Pause) 1022M->1022M(1024M) 253.734ms [5.814s][info][gc] GC(56) Pause Full (G1 Evacuation Pause) 1022M->1022M(1024M) 262.700ms [5.814s][info][gc] GC(55) Concurrent Cycle 517.345ms [5.815s][info][gc] GC(57) Pause Young (Normal) (G1 Evacuation Pause) 1022M->1022M(1024M) 0.458ms [5.832s][info][gc] GC(58) Pause Full (G1 Evacuation Pause) 1022M->0M(1024M) 16.349ms Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at org.example.App.main(App.java:14) |
As expected, Java 11’s G1 GC is trying to do its best to keep up with the fury of objects being carelessly created. However it eventually dies with a OutOfMemoryError as seen on the last line.
Let’s take a look with the the Epsilon no-op GC. Since this is an experimental feature, we also need to include the -XX:+UnlockExperimentalVMOptions in the follow java command.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
mvpjava@jetbrains:~/IdeaProjects/java-eclipse-gc$ java -cp target/java-eclipse-gc-1.0-SNAPSHOT.jar -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xms1G -Xmx1G -Xlog:gc org.example.App [0.001s][warning][gc] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups [0.004s][info ][gc] Non-resizeable heap; start/max: 1024M [0.004s][info ][gc] Using TLAB allocation; max: 4096K [0.004s][info ][gc] Elastic TLABs enabled; elasticity: 1.10x [0.004s][info ][gc] Elastic TLABs decay enabled; decay time: 1000ms [0.004s][info ][gc] Using Epsilon Starting ... [0.176s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 53858K (5.14%) used [0.216s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 104M (10.21%) used [0.255s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 156M (15.29%) used [0.289s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 208M (20.37%) used [0.327s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 260M (25.45%) used [0.366s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 312M (30.53%) used [0.406s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 365M (35.69%) used [0.446s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 417M (40.77%) used [0.485s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 469M (45.85%) used [0.524s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 521M (50.93%) used [0.563s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 573M (56.01%) used [0.604s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 625M (61.09%) used [0.647s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 677M (66.16%) used [0.695s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 731M (71.44%) used [0.753s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 783M (76.52%) used [0.799s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 835M (81.60%) used [0.848s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 887M (86.68%) used [0.898s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 939M (91.76%) used [0.950s][info ][gc] Heap: 1024M reserved, 1024M (100.00%) committed, 991M (96.83%) used Terminating due to java.lang.OutOfMemoryError: Java heap space |
The above test ran without any garbage collection interruptions until the OOM Exception occurs. This made the code run much faster as well as utilize less CPU resources. With this predictable behavior, you’re now free to tackle the testing use cases mentioned above.
Lazy isn’t always bad after all, thanks Epsilon!