The palette of Java garbage collection options available on the market today includes several that are classified as mostly concurrent. They intend for garbage collection to happen concurrently with application execution. However, "supplementary to mostly concurrent" is "partly non-concurrent." There are instances where GC modes get overloaded, at which time they fall back on 'stop-the-world' pausing to catch up, and applications are completely frozen until the garbage collection cycle finishes.
The only fully concurrent JVM proven for production server workloads today is Zing®. No matter how fast your application mutates the heap, Zing® C4 collection algorithm keeps up using an adaptive GC scheduling technique leveraging parallel processor resources. By utilizing 'quick release', freed memory is available quickly for the relocation of objects and for the application. By keeping GC operations out of the way of mutator threads, Zing permits any size of of memory footprint, from 1GB up to 2TB, while avoiding longer pause penalties at higher footprints. With Zing® you can benefit from:
Further explore your Java garbage collection options by watching our video about Java garbage collection by Azul's CTO Gile Tene.