Thanks for raising this, Volkan. I agree with your assessment that scoped values won't be very helpful for object pooling.
The first sentence of https://openjdk.org/jeps/446 states: > Introduce scoped values, which enable the sharing of immutable data within > and across threads. The key pieces of the description are "immutable data" and "across threads". We pool objects (rather than using singletons) because they are required to be stateful: acquired, used/mutated, reset, and returned. While threadlocal gives us some level of threadsafety (no other thread can acquire a value from the current threads threadlocal), the scoped value may be read from all threads in the scope -- the general advantage is that data isn't duplicated, and doesn't need to be because it's immutable, so it may safely be shared, however this characteristic makes it unhelpful for recyclers where it's important that at most a single consumer can acquire an object at any point in time. I suspect scoped values may work nicely for detecting recursive logging (even across async appender threads in a way that our current threadlocal cannot detect) but I don't want to distract from the intent of this thread! Best, -ck On Mon, May 29, 2023, at 15:48, Volkan Yazıcı wrote: > Hello, > > In #1401 <https://github.com/apache/logging-log4j2/pull/1401> against the > `main` branch, I am working on moving JSON Template Layout's "recycler" > concept to `log4j-core` and replacing all `ThreadLocal` usage with that. We > want to know if there are opportunities to take advantage of scoped values > (SVs), which will be introduced with JEP 429, and if so, accommodate them > in the recycler abstraction. > > In its current form, the recycler is designed to offer [reusable] object > pooling to facilitate garbage-free logging. Log4j components (appenders, > layouts, etc.) will work against the recycler API and users will either > choose one of the provided implementations (no-op, concurrent queue, queue > in a `ThreadLocal`) or provide theirs. > > I am not able to see how SVs would help us with object pooling and, hence, > the recycler API. I would appreciate some feedback on this. > > Kind regards.
