Hi Volkan, Beyond StringBuilder instances, we attempt to clear references from all thread local references to avoid substantial overhead. In practice this works nicely because it reinforces java performance characteristics. Java threads are fairly memory expensive (not to mention the cost of initialization) so the threadlocal object overhead from log4j tends to be inconsequential by comparison. Applications in memory constrained environments already have relatively few threads, and applications which constantly create and destroy threads tend not to worry about the performance of creating log events because it's inexpensive compared to thread initialization. Have you observed a problem? We've found and resolved a few issues over the last year or so where references were held longer than expected. If you're aware of places we're using more memory than we should, please file a ticket :-)
-ck On Sat, Dec 28, 2019, at 18:13, Remko Popma wrote: > Ralph is correct. > When running in a servlet environment (J2EE), Log4j2 automatically > does not use ThreadLocals because of the problems associated with > threadpools in those environments. > This is documented in the manual: > https://logging.apache.org/log4j/2.x/manual/garbagefree.html#Config > > In addition, we did some work to ensure that the StringBuilders in > ThreadLocals do not grow beyond some configurable maximum size to > ensure that memory consumption remains reasonable. > > I don't remember the reason why AbstractStringLayout#getStringBuilder > does not check log4j2.enableThreadlocals. This may be an oversight, I > am not sure. I will take another look when I have time. > > Remko. > > On Sun, Dec 29, 2019 at 7:27 AM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > Many of the ThreadLocals were added in the effort to make much of Log4j be > > garbage free. As I recall Remko did some performance tests on various > > alternatives and what we have is a result of that. But that is just my > > recollection. > > > > Ralph > > > > > On Dec 28, 2019, at 2:39 PM, Volkan Yazıcı <volkan.yaz...@gmail.com> > > > wrote: > > > > > > Regarding log4j2.enableThreadlocals configuration knob, it feels more > > > like a hint rather than a hard restriction. See how > > > AbstractStringLayout#getStringBuilder() doesn't take that flag into > > > account. > > > > > > On Sat, Dec 28, 2019 at 10:10 PM Volkan Yazıcı <volkan.yaz...@gmail.com> > > > wrote: > > >> > > >> Hello, > > >> > > >> I see that many Log4j components rely on TLA for efficiency reasons. > > >> There I have two main concerns: > > >> > > >> 1. TLAs, for obvious reasons, entail an extra memory cost on > > >> threads, particularly, even when they are not used. Consider > > >> a thread invoking a Log4j flow where various TLAs are > > >> performed. That storage will keep on occupying the memory > > >> until the next time it gets used. > > >> > > >> 2. JEE servers are known to accommodate quite some threads, > > >> e.g., the the default thread count is 200 for Tomcat[1]. TLAs at > > >> will will certainly have an impact on context switching costs too. > > >> > > >> Is there a convention recommended in this domain? In > > >> log4j2-logstash-layout, I favor object pools over TLAs. Object pools > > >> offer better memory utilization with the cost of synchronization. I > > >> see that many text-based Log4j 2.0 layouts rely on > > >> ThreadLocal<StringBuilder>s. While it performs pretty good, I am > > >> struggling with the idea of associating a large(?) text chunk next to > > >> each thread who has at least once attempted to log something. > > >> > > >> Best. > > >> > > >> [1] > > >> http://tomcat.apache.org/tomcat-5.5-doc/config/http.html#Common_Attributes > > > > > > > >
