TransGC : Concurrent Garbage Collection using Hardware Transactional Memory

In the last few years, managed runtime environments such as the Java Virtual Machine (JVM) are increasingly used on large-scale multicore servers. The garbage collector (GC) represents a critical component of the JVM and has a significant influence on the overall performance and efficiency of the running application. We perform a study on all available Java GCs, both in an academic environment (set of benchmarks), as well as in a simulated reallife situation (client-server application). We mainly focus on the three most widely used collectors: ParallelOld, ConcurrentMarkSweep and G1. We find that they exhibit different behaviors in the two tested environments. In particular, the default Java GC, ParallelOld, proves to be stable and adequate in the first situation, while in the real-life scenario it results in unacceptable pauses for the application threads. We believe that this is partly due to the memory requirements of the multicore server. G1 GC performs notably bad on the benchmarks when forced to have a full collection between each of the 10 iterations of the application. Moreover, even though G1 and ConcurrentMarkSweep GCs introduce significantly lower pauses in the client-server environment than ParallelOld, they could still seriously impact the response time on the client. Pauses of around 3 seconds would make a real-time system unusable and could disrupt the communication between nodes in the case of large-scale distributed systems.