Re: [log4j] Recycler and Scoped Values (JEP 429)

[Matt Sicker]

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  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  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.

Re: [log4j] Recycler and Scoped Values (JEP 429)

[Carter Kozak]

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  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.

[log4j] Recycler and Scoped Values (JEP 429)

[Volkan Yazıcı]

Hello,

In #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.