En sistemas Java de baja latencia, optimizar las asignaciones de memoria y eliminar el trabajo redundante puede rendir más —y alterar la elección— que cualquier ajuste del recolector de basura. Un benchmark de latencia evento-respuesta ejecutado con JLBH sobre Chronicle-FIX ilustra esta idea con un ejemplo concreto: una sola línea de log SLF4J por mensaje.
En la prueba, con un único registro SLF4J añadido, el p99 oscila entre 12 y 16,86 microsegundos según el recolector (ZGC, G1, Shenandoah o Parallel), mientras que el p99.99 ronda los 19–20 milisegundos; a 50.000 mensajes por segundo, eso equivale a unas 300 incidencias por minuto. Cambiar la escritura de logs a tmpfs reduce el p99 a 10–11 microsegundos y el p99.99 a 9–10 milisegundos, igualando en rendimiento a la mayoría de recolectores.
El cambio decisivo llega al suprimir ese log redundante —Chronicle-FIX ya graba cada mensaje internamente mediante Chronicle Queue—. El p99 baja unos 2 microsegundos adicionales, pero el p99.99 cae tres órdenes de magnitud (a 8–9 microsegundos en Parallel, ZGC y G1+COH). Además, el ranking de recolectores se invierte: Parallel GC pasa a liderar y Shenandoah queda último en p99.99. El autor concluye que la elección del GC depende del workload, por lo que conviene optimizar primero la carga y solo después seleccionar y ajustar el recolector.