I like the idea, but I defer to the benchmark results for this sort of thing ;-)
The ability to bound reusable objects below the thread count will become more valuable when project loom[1] is released, as the JVM will support millions of virtual threads on a handful of OS threads. This will make the current threadlocals more expensive because they're no longer a rounding error of heap compared to the cost of a thread. Not to mention the ability to disable threadlocals on a per-thread basis[2]. On a related note, I've been thinking about how valhalla[3] might impact logging. It's still a long way off and many of our consumers lag behind java versions, but it's interesting to consider how we may be able to remove some threadlocals and recyclers in favor of primitive logevent and message types to improve both performance and legibility. -ck 1. http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html 2. https://github.com/openjdk/loom/blob/5cef9850a4f19c6897c9d142d954490a718ecdc2/src/java.base/share/classes/java/lang/Thread.java#L822-L829 3. http://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html On Thu, Nov 19, 2020, at 10:45, Volkan Yazıcı wrote: > Hello, > > As you might have already known, JSON template layout uses RecyclerFactory > for recycling objects to maintain a certain memory footprint, that is, work > garbage-free. By default there are 3 recycler factory implementations > shipped: dummy, thread-local, and queue. (See the relevant part of the > manual > <https://logging.apache.org/log4j/2.x/manual/json-template-layout.html> for > details.) I want to use this abstraction throughout the Log4j code base > rather than implicitly relying on ThreadLocals. > > What do you think about this? > > Kind regards. >
