ppkarwasz commented on issue #3819: URL: https://github.com/apache/logging-log4j2/issues/3819#issuecomment-3067246866
> Just out of curiosity, what is exactly the use case for the pooling of those builders? When are they supposed to be used? We have some users in latency-sensitive domains such as finance, where minimizing or eliminating Garbage Collection (GC) pauses is important. For that reason, Log4j Core supports a [Garbage Collection-free (GC-free) mode](https://logging.apache.org/log4j/2.x/manual/garbagefree.html), designed to reduce object allocation during logging. The goal is to maintain short and predictable request latencies by avoiding the creation of temporary objects that could trigger a GC pause. While modern JVMs have greatly improved in this area, earlier versions made GC much more disruptive—often involving stop-the-world events that could introduce significant latency spikes. In GC-free mode, Log4j reuses internal objects like `LogBuilder`s and `Message`s via thread-local pooling instead of creating new ones on every log call. This recycling is key to keeping allocations to a minimum. This pattern can also be applied in servlet containers—but with a caveat: to avoid classloader-related memory leaks (like the one mentioned in this issue), Log4j Core must be loaded by the server's *shared* or *common* classloader, not the webapp classloader. For Apache Tomcat, I’ve documented this setup, along with some supporting components, here: 👉 [Copernik.eu extensions for Log4j Core and Tomcat](https://oss.copernik.eu/tomcat/3.x/guide) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
