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.

Reply via email to