Thread-local successor for object pooling

[Alan Bateman]

On 31/10/2022 10:20, Volkan Yazıcı wrote:
> Hello,
>
> Log4j heavily relies on thread-locals (TLs) for object pooling.

It would be interesting to know if log4j has done any recent evaluation 
with newer JDK releases and GCs to see their object pooling has a 
positive or negative benefit. It would also be useful to get a summary 
of what they are caching. Examples such as SimpleDateFormat are 
expensive to create and aren't thread safe but have immutable and thread 
safe alternatives.


> This becomes of particular importance for caching and garbage-free 
> logging purposes. With JEP 425 (Virtual Threads), this becomes 
> problematic due to two main issues:
>
> 1. TLs on vthreads yield no allocation benefits since vhtreads are 
> short-lived. On the contrary, it becomes a redundant memory cost due 
> to the excessive vthread count. In this case, Log4j still works, 
> though slower and with increased memory footprint.
>
> 2. TL mutation can be disabled for vthreads. In this case, Log4j 
> doesn't work, since TL setters throw UnsupportedOperationException.

That's right but not specific to virtual threads. It is also possible to 
create platform threads that do not support TLs. This is something that  
we need a lot more feedback on before deciding if that part of the API 
should be made permanent.

BTW: The LOG4J2-3622 issue linked appears to be Helidon Nima issue in 
that it needs to work with general purpose libraries.

-Alan.