Based on how similar concepts like Reactor’s Context or Kotlin coroutine contexts, I think the main use case for us would all revolve around the ThreadContext API. I agree that scoped values’ immutable characteristics would make them not very useful for object reuse purposes.
> On May 31, 2023, at 2:55 PM, Carter Kozak <cko...@ckozak.net> wrote: > > 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.
