Thread-local successor for object pooling

[Volkan Yazıcı]

Hello,

Log4j heavily relies on thread-locals (TLs) for object pooling. 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.

Users experimenting with Java 19 have already started reporting these
issues[1]. JEP 429 (Scoped values) might be the answer to our questions,
yet I have the impression that there will be a time gap between the GA
releases of vthreads and SVs. Hence I would like to know what is the best
angle to address this problem using the tooling that will be provided by
JEP 425.

I believe our use cases apply to many other major libraries in the wild. I
would appreciate it if OpenJDK developers can help us with determining a
way forward.

Kind regards.

[1] https://issues.apache.org/jira/browse/LOG4J2-3622
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20221031/854b006e/attachment-0001.htm>