Java garbage collector proposal aimed at performance testing

The Epsilon project could benefit testers, but it wouldn't bring manual memory management to Java

Java could be getting a garbage collector that allocates but does not reclaim memory, providing special testing benefits.

A draft Java proposal recently floated named Epsilon GC calls for development of a garbage collector that handles only memory allocation. Authored by OpenJDK contributor Aleksey Shipilev, a principal software engineer at Red Hat, the proposal is described as offering an "arbitrarily low-overhead garbage (non)-collector." Shipilev hopes to provide a passive runtime garbage collector implementation with a bounded allocation limit and minimum runtime performance overhead, though he does not seek to introduce manual memory management features in Java or the JVM.

While common garbage collection testing tests would not be suitable for Epsilon, it would be helpful for performance testing; a garbage collector that does "almost nothing" is useful for performance analysis for other, real garbage collectors, the proposal states. The plan also could be useful for functional testing of code, providing a way to establish a threshold for allocated memory. Virtual machine interface testing, another possible use, would benefit in that having a simplified garbage collector helps with understanding the minimum required from a VM GC interface to have a functional allocator.

Epsilon also could provide "last drop" performance benefits, for "ultra-performance-sensitive applications" where developers are sensitive about memory allocations and know an application's memory footprint. They also could arrive at almost completely garbage-free applications. "In those applications, GC cycle may be considered an implementation bug that wastes cycles for no good reason. Extremely short-lived jobs are one example of this," the proposal states.

Copyright © 2017 IDG Communications, Inc.

How to choose a low-code development platform