Java performance testing — Epsilon garbage collector
For many people that may be a trivial issue, but I have just learned that there is a special kind of garbage collector in JVM that is useful during performance testing (available since Java 11).
What does a garbage collector in JVM do?
The JVM garbage collector is responsible for allocating memory and releasing it. The second task is kind of what we expect, but it is worth noting that the garbage collector also allocates the memory.
Epsilon garbage collector
The Epsilon garbage collector only allocates memory. It cannot release any allocated memory, so the application is very likely to crash because of an OutOfMemoryError. It is a terrible idea in production, but it has some significant advantages when we are doing a performance test of an application.
The most significant advantage is no GC overhead. The JVM does not pause to clear the memory because it does not even try to release any memory. The garbage collector does not affect the result of the test.
It means that for the first time on JVM, when we do a performance test, and we see terrible results, we no longer have an excuse: “probably GC stopped the process for a while.” Now, a bad outcome of a test is our fault exclusively.
Parsing machine learning logs with Ahana, a managed Presto service, and Cube, a headless BI solution
Check out my article published on the Cube.dev blog!
How to use the Epsilon garbage collector?
It is one of the experimental features, so first of all, we need to unlock the experimental features using this JVM runtime parameter:
Then we can add another JVM parameter which changes the garbage collector used by the process:
- Data/MLOps engineer by day
- DevRel/copywriter by night
- Python and data engineering trainer
- Conference speaker
- Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
- Twitter: @mikulskibartosz