<div dir="ltr"><div dir="ltr">I'm wondering if we can create a new ThreadLocal replacement for virtual threads?<br><div><br></div><div>I call this alternative PlatformThreadLocal. It differs from ThreadLocal in that it is based on platform threads and can be shared among multiple virtual threads.<br></div><div><br></div><div>If we don't want to share it between virtual threads, we need to call a method called 'pin' to get the value and call the 'unpin' method when we are done using it (or use the try-with-resources statement):<br></div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>static 

PlatformThreadLocal<SomeValue> cache = 

PlatformThreadLocal.withInitial(/* heavy initialization */);</div><div><br></div><div>void foo() {</div><div>    try (ThreadLocal<SomeValue>  pinnedCache = cache.pin()) {</div><div>        SomeValue value = 

pinnedCache.get();</div><div>        // use the value</div><div>    }</div><div>}</div></blockquote><br><div>For platform threads, the 'pin' method should return the 'cache' itself;<br></div><div><br></div><div>For virtual threads, the 'pin' method will pin the value of the platform thread on the current virtual thread, until the 'unpin' method is called.</div><div>During this time, if another virtual thread running on the same platform thread tries to pin the value, it will get a new ThreadLocal value associated with the current virtual thread.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 31, 2022 at 6:21 PM Volkan Yazıcı <<a href="mailto:volkan@yazi.ci">volkan@yazi.ci</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div><div>2. TL mutation can be disabled for vthreads. In this case, Log4j doesn't work, since TL setters throw UnsupportedOperationException.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><br><div>Kind regards.</div><div><br></div><div>[1] <a href="https://issues.apache.org/jira/browse/LOG4J2-3622" target="_blank">https://issues.apache.org/jira/browse/LOG4J2-3622</a></div></div>
</blockquote></div></div>