I did not understand your remark about benchmarks. The recycling strategies are there mostly to address memory concerns, not performance. For instance, thread-locals are not a preferable option for apps that run on hundreds of threads, which is the case in most Tomcat apps. Or am I missing a point here?
Loom will indeed be the biggest Java flagship feature released after annotations and/or lambda, IMHO. Though it is still yet to be decided on how to approach scoped variables there. Nevertheless, an abstraction on the employed recycling strategy will give us sufficient room to adopt developments in the JVM. Regarding your remark about the object model in Valhalla, I don't think it will help us to totally avoid the need for recycling. Consider StringBuilder's spread all over the code base or TruncatingBufferedWriter's I have in JTL to perform garbage-free stack trace dumps. On Thu, Nov 19, 2020 at 5:09 PM Carter Kozak <cko...@ckozak.net> wrote: > 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. > > >
